plone.resource provides simple way to drop in static media files in your Plone
http://pypi.python.org/pypi/plone.resource
However, the usage of plone.resource has not been explained from the system admin / front end developer perspective. The current documentation outlines the process from Zope 3 developer perspective only and does not give a full story how to add egg to the buildout, how to connect files to portal_javascript and so on.
What are the best practice just to "drop in a static media folder" for your Plone, where you then can register entries for portal_css and portal_javascript?
plone.resource is a framework component. The documentation you seek needs to sit in packages that use plone.resource to accomplish the type of "admin experience" you are describing. The most obvious example is plone.app.theming, which does have this type of information in its documentation.
Related
I have an Alfresco module that I would like to have do some cleanup when a new version of it is installed.
In the current situation, an older version of the module created a folder node with custom properties at the root of the repository. We've since decided to have multiple such nodes, and none of them at that location. I'd like to put into the next version of the module code that would run at Alfresco startup, check for the existence of the old node, copy its properties into the appropriate new nodes, and delete the old node.
Is such a thing possible? I've looked at the Bootstrap configuration file, but that appears to only allow one to add things to the repository, not modify or delete them.
My suggestion is that you write a patch. That is a class that implements
org.alfresco.repo.admin.patch.AbstractPatch
Then you can do pretty much anything you want on bootstrap (except executing searches against solr since it wont be available).
Add some spring configuration, take a look at the file patch-services-context.xml for inspiration.
Yes you can do that, probably you missed the correct place in the documentation about that:
If you open Import Strategy you'll find a section Per BootstrapView, you should be using something like REPLACE_EXISTING or UPDATE_EXISTING for your ACP packaged content (if you're using ACPs as your bootstrap importing strategy).
Here is a more detailed description of the UUID Bindings values.
Hope that helps.
You can use patches.
When alfresco server starts it applies patches and executes database updates etc.
Definition :
A patch is a piece of Java code that executes once when Alfresco
Content Services starts. Custom patches can be implemented.
Documentation Link
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
"Moving a view to a host with the same architecture or to a NAS device"
"Moving a view to a host with a different architecture": it involves a cleartool reformatview -dump/-load in addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
I am looking at a URL that ends in .sdo, as in
http://somesite/somefolder/doc.sdo
I know that if you have an asp.net site the files will end in
http://somesite/somefolder/doc.aspx
I also know that oracle has something called "sdo" -- but I don't totally understand what it does.
http://docs.oracle.com/cd/E15523_01/integration.1111/e10224/sca_sdo_ejb.htm#CCGHEBJF
What kind of platform supports sdo?
Check out this link - http://filext.com/file-extension/SDO
The SDO file type is primarily associated with 'DB/TextWorks' by Inmagic, Inc.. Inmagic TextWorks and WebPublisher PRO together provide a do-it-yourself customizable solution for information management.
.sdo is for DB/TextWorks (Database Deferred Update Directory)
We have a requirement that on a page publish, we need to:
Find a component presentation that has a component based upon a particular schema.
Extract certain field vales from that component and store them in a custom database table that's available to our .NET application (on the Content Delivery side).
I think this is a good candidate for either a Deployer extension or a Storage extension - but I'm a little unclear which and why having never written either?
I've ruled out the Event System as this kind of code would be located on the CM, which seems like the wrong "side" to me - my focus is on extending what happens on the CD-side after a page is published.
Read a few articles on Tridion World (this, this, this and this) and I think a storage extension would be the better choice?
Mihai's article seems to be very close to what we need, where he uses a new item type mapping:
<ItemTypes defaultStorageId="brokerdb" cached="true">
<Item typeMapping="PublishAction" cached="false" storageId="searchdb" /></ItemTypes>
But how does Tridion "know" to use this new item type when content is published, (its not one of the defined TYPE_NAMEs, which is kind of the point)?
I should clarify I'm a .NET/C# dev not a Java dev so this is probably really obvious to Java people - apologies if it is!
Cheers
Tridion will not know by default how to deploy your new entity. My advise is to create a Deployer Module (your links should give you enough information about how you can do that) that executes in post-processing phase (of the deployment process), that processes all components from the deployment/transport package, extracts the needed information and uses a custom Storage Extension to store the needed information.
Be careful: you need to set-up in config your new type but you also need to use it yourself from that Deployer Module.
Hope this helps.
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.