Reading https://pypi.python.org/pypi/five.pt/2.2.1
To enable Chameleon, configure the package using ZCML:
<include package="five.pt" />
Are Chameleon templates enabled per-package or globally? Instructions are little sparse.
If I want to enable Chameleon for a particular package only is it possible? (making migrating to Chameleon easier)
To quote directly from the PyPI page for the package:
It works using monkey-patching onto the existing API (specifically, the TALInterpreter and PageTemplate classes). In simple terms, what the patching does is to replace the TAL interpreter class and make sure that the so-called "cooking" routine uses the Chameleon parser and compiler instead of the zope.* reference implementation.
So, when you load the five.pt package, the regular page templates code is patched to use Chameleon templates instead when templates are cooked (compiled).
That really precludes enabling Chameleon and disabling Chameleon on a package-by-package basis. Once any packages uses the <include package="five.pt" /> directive, the five.pt configure.zcml file is loaded and the patch is applied.
That said, theoretically it should be possible to add per-package enabling or disabling back into the patch; the __call__ and cook methods of the five.pt Program utility would have to be taught how to detect what package the template applies to and make a decision on what RepeatDict class and page template object to use.
Related
I am trying to build a control panel following a tutorial on the Plone Documentation site.
http://docs.plone.org/develop/plone/functionality/controlpanel.html
However, I started off creating the product with (from the src folder) ../bin/zopeskel plone my.product, instead of creating with the dexterity option. I did select the easy option when it asked what mode I wanted and I did select yes when it asked if I wanted to create a GS Profile.
I made sure to include grok in configure.zcml
<include package="five.grok" />
After following the instructions, I try to run the quickinstall to install the product, but it gives me the error:
ImportError: No module named directives
referring to the line in the settings.py file of their tutorial
from plone.directives import form
I added plone.app.registry to the install_requires bit in the setup.py file, and I made sure to make the changes in the configure.zcml file to include
Just for experimenting, I did add 'plone.app.dexterity' to the install_requires, but I still got the same error.
Is grok conflicting with plone.directives? If so, how can I fix this or do I have to use deterity instead of plone as the option for creating products?
If grok is not conflicting, what could the problem be?
On a side note, the tutorial does appear to be for using dexterity to create the product, but I am not sure if that is what the problem is.
I created a gist with a howto that I wrote for plone.org some time ago:
https://gist.github.com/tisto/4ef1f6c7b445faf6ad73
This is considered best practice these days. Using grok is not recommended any longer.
I'm attempting to modify/override functionalities of the CQ client library manager and I was wondering if anyone is familiar with where the code lives?
I've found some js that controls channel detection in DefaultChannelDetector.js and CQClientLibraryManager.js which seemingly only deals with channels, not dependencies or embedding. These are served as a clientlib, etc/clientlibs/foundation/librarymanager.js which I assume can be overriden by pointing htmllibmanager.clientmanager in apps/system/config/com.day.cq.widget.impl.HtmlLibraryManagerImpl.config
So for modifying, I would need to know where the code lives. For overriding, I assume I point the htmllibmanager.clientmanager toward something else but I would still need to know how to access dependencies/categories/embed properties of clientlibs.
Additionally, any low-level insight into how the cq:includeClientLib tag works would be appreciated. (low-level as in point to the code that implements it)
The vast majority of the Client Library functionality is in the HtmlLibraryManager component implemented OOB by the HtmlLibraryManagerImpl class in the com.day.cq.cq-widgets bundle. You can look up this component in Felix to see what bundle it is in and then decompile that bundle if you need to look at the guts of what the implementation does.
At a high level this component handles both the generation of the results of the cq:includeClientLib tag and the concatenation and compilation of libraries when a library URL is requested. Speaking specifically to the cq:includeClientLib tag, the HtmlLibraryManager's writeIncludes method will determine, based on parameters of the request and parameters provided in the cq:includeClientLib tag, how to write includes to the page for the existing libraries.
In the case of dynamic libraries (libraries which are channel based) it will write calls to the library manager JavaScript mechanisms which will dynamically include libraries based on the user's channel. Otherwise appropriate script and link tags for JavaScript and CSS respectively will be written for the requested libraries and their dependencies.
I'm using the SquishIt to manage the js/css files and it works perfect, but only with my manually created files. How can I use it with the asp.net webresources/script resources (scripts for ajax, validation etc.) which are returned to browser throught the script manager?
A method on bundles called .AddRootEmbeddedResource has been added to deal with situations like this (where an embedded resource does not use the default AssemblyName.ResourceName convention)
I've struggled with a better solution for the following setup. I'm not actively working on this, but know some that might appreciate other ways of handling this.
Setup:
Tridion-managed page has a single "linked list" component Linked list
Single component has component links to other components in Tridion
Linked-to components often link to multimedia component (mm)
An XSLT component template (XSLT CT) renders XML with above content and with links to PDF
XSL document() function used to grab embedded (linked-to) content, all content converted to XML nodes and attributes
TCMScriptAssistant namespace with publishBinary() publishes related PDF and other media
Page template just outputs the result of the CT
Business requirements:
improved publishing (last I worked on this, some of these files created a 2GB publishing transaction because of the PDFs)
published XML content file must reference the associated PDFs; hyperlinks work but identifiers might not help because of...
no Tridion content delivery APIs, mainly for independence from the storage database but also to avoid Tridion-specific code on the presentation server (loosely coupled setup and less training for developers)
The biggest issue is the huge transport package during publishing. The second problem is publishing any of the linked-to PDFs will cause the page to republish.
How could this setup be improved or re-engineered, preferably without too many changes to the existing templates, though modular templating could be considered.
Dynamic component presentations could possibly work, but would need to be published to the file system and not use dynamic linking or broker objects (e.g. no criteria filters, binary metadata, etc).
There are indeed 2 questions. I will handle them in reverse order.
To prevent the page from being republished when you publish a binary, you can use the event system in older versions of Tridion (pre-2011) to turn off link resolving, or with newer versions you can use a custom resolver to prevent this. There is an article by Nuno which explains this(http://nunolinhares.blogspot.com/2011/10/tridion-publisher-and-custom-resolvers.html)
Your second one is a bit tougher, in no small part because of your criteria for not using the SDL Tridion CD APIs. I would have suggested publishing the binaries separately (this would keep the file size down of your transaction package), and using Binary Linking to resolve the paths at request time.
Given this is not an option, I think the only was I would approach it would be to still use dynamic component presentations, and then use predictable unique file names for the PDfs (i.e. use something like 317-12345.pdf based on the URI), and use one directory for all the binaries. That way you could enter the paths to the binary using your XSLT template, as you know where the binaries will be located later. You could then use a custom resolver to publish the binaries when you publish the main list component or page.
Hope that helps
Chris
I need to develop a whole section of a website (around 10 different pages) as a DotNetNuke module. The site will be using DNN as the CMS, where editors will manage HTML content for most of the website (exception that section I'll be developing).
I've already made a rather extensive research on DNN Module Development (even watched some recorded Webinars by DNN Corp). Unfortunately, most of what I could find online is about developing simple, widget-like modules. Also, most of it uses a step-by-step "how to use visual studio to acomplish x" approach, while I was trying to understand how DNN works. So it seems I have to figure it out for myself...
At this point I'm already somewhat familiar with DNN, and I see several different solutions to my problem:
Creating a module for every page on my custom section. I don't like this idea very much, specially because I have code that need to be shared across multiple pages.
Developing a single module with several User Controls inside (one for each page), and use custom module settings to let each page know which control to display.
Develop a "bogus" module that will work as a library, and additional modules for each page.
Develop the library module, then use the Razor Host Module and Razor scripts for the views (I don't need/want WebForms on my app).
So I decided to ask you guys for advice. Which is the the preferred way to go? Maybe none of the above? I know all four options above should give me the result I want, but I also don't want to go against the "DNN way" too much...
I wouldn't recommend #1 (multiple modules) or #3 (also multiple modules) at all, and though #2 (single module w/ module level setting that determines view) is definitely a solid option used widely by DNN module developers, it sounds like you'd prefer #4 (Razor) over #2 because you like the development style.
So - I'd recommend going with the Razor approach, which though it seems like you understand the approach just fine, I wanted to elaborate on for posterity:
Build a library (assembly/DLL) to encapsulate all of your reusable business logic
Build out Razor views for each page that make use of that logic and render your data on the page
Drop the Razor Host module on each page that you need it and point it to the correct view
That should work out quite well.
I'm assuming you're looking at developing your software in the "Web Site Project" style. I'll like to recommend that you look at the "Web Application Project" style of doing things.
If you have shared functionality in a library, feel free to build an assembly and drop it in the bin folder, from there, it will be picked up by DNN and it will run in the http context, which is great!
Build your module in one project and package the different modules in your DNN manifest.
Hope i'm not talking about what you understand.
Added another answer, it's a post in itself.
Modules - That's a term that's very loosely used by all of us.
Clearer Definitions
Package = Zip file (Not Module)
Manifest = .DNN file
The manifest allows you to define Modules(group of View/Edit/Settings) user controls as a single installation package.
In the DNN 3.0 manifest, if you're still in this format, you'll notice that a basic single installation package is structured like this (briefly)
<dotnetnuke version="3.0" type="Module">
<folders>
<folder>
<name>Side bar Navigation</name>
<modules>
<module>
<friendlyname></friendlyname>
<cachetime>0</cachetime>
<controls>
<control>
<title>View</title>
<src>DesktopModules/Module/View.ascx</src>
<type>View</type>
</control>
<control>
<key>Settings</key>
<title>Settings</title>
<src>DesktopModules/Module/Settings.ascx</src>
<type>Edit</type>
</control>
</controls>
</module>
</modules>
<files>
...
</files>
</folder>
</folders>
</dotnetnuke>
So that above defines a Single Module in an Installation Package.
In the context of a blog, you would have 2 modules
Blog Display Module (displays a selected blog or just the whole lot)
Sidebar Navigation Module (Helps you
to display quickly the blogs you've
written for an any period of time)
What you can do is to package the Blog Display Module in the manifest in a copy of <folder></folder> and then the Sidebar Navigation Module in another copy of the <folder></folder> structure.
For example, this project has 7 modules; Side bar navigation, custom search module, blah blah blah
<dotnetnuke version="3.0" type="Module">
<folders>
<folder>...</folder>
<folder>...</folder>
<folder>...</folder>
<folder>...</folder>
<folder>...</folder>
<folder>...</folder>
<folder>...</folder>
</folders>
</dotnetnuke>
1 Installation Package (Which means 1 Web App Project)
7 Modules
One assembly to place in the bin/
All code is shared and you can then inherit from other library references to develop further.
They have different views, names, friendlynames but all share one common <foldername>
The KEY is in the Packaging.
<folder>
<name>BlogDisplay</name>
<friendlyname>Blog Display</friendlyname>
<foldername>WebLog</foldername>
<modulename></modulename>'
'<folder>
<name>BlogSidebar</name>
<friendlyname>Sidebar Navigator</friendlyname>
<foldername>WebLog</foldername>
<modulename></modulename>
It'll look something like this! that's where foldername is. It defines where in DesktopModules your module will be installed to.
In DNN 5 books, the Web Site Project method of development is still in use but when you're participating in development on the Core Modules, you'll find that the projects are in Web App Project development style, which is better, because all your code-behind is in an assembly and not exposed as source code on the web.
You're definitely on the right path.