Hi guys,
Just a couple of notes of things that itched me after reading your
mails (basically things that we'd need to document asap...)
* Remember that the "samples" module is more of showcase of
paragraphs, templates, dialogs than an example on how to do a module.
* The SamplesConfig class' purpose is two-fold: 1) showcasing the
fact that the class registered as <class> in your module descriptor
(mymodule.xml) is populated with the contents of /modules/mymodule/
config, 2) holding that configuration and providing it to templates,
so that, for example, adding a paragraph there automatically adds it
to the list of paragraphs available to templates using it. As pointed
out before, and as noted in the javadoc, SamplesModuleConfigHelper is
just a helper/wrapper around SamplesConfig.
* ModuleVersionHandlers, and specifically those extending Abstract/
DefaultModuleVersionHandler are meant to maintain module's
configuration and files and allow developers to incrementally update
them, version-per-version while keeping potential customisations made
by users of said modules. Now, if your modules only contain content
(paragraph, dialog, template definitions and files), you're maybe
better off implementing your own ModuleVersionHandler, which would
systematically re-bootstrap and re-extract all content. Such a MVH
would maybe be a good candidate for inclusion in the main codebase,
so feel free to contribute :) If you're looking for examples and look
at the CoreModuleVersionHandler, you'll probably be confused, because
1) 3.5 was the first version of core as a module, so we had to deal
with detecting if we were really installing, or updating from 3.0 2)
it has plenty of changes. A better example for what could be
considered a "regular" MVH is DMSModuleVersionHandler. Also note that
you don't need to specify a <versionHandler>, nor a <class>, for that
matter.
HTH,
greg
On Jan 16, 2008, at 19:15 , Ryan Gardner wrote:
On Jan 16, 2008, at 10:59 AM, David Smith wrote:
Hi folks,
As we're moving our work into Magnola 3.5, we thought it would
make sense to
go ahead and break our customizations into a module, rather than
having it
all mixed in with Magnolia's source as we have done previously.
Yeah, Modules are definitely the way to go. I copied the samples
module and gutted out the stuff I didn't need and used that as a
starting point.
Here's my general workflow for developing stuff to go into a module.
For paragraph templates, I start with the jsp file. I create the
jsp file based on what data I want to output, and take note of it.
Then I copy the jsp file for the paragraph template over to a
version of magnolia running on my development machine. There, in
the admin-interface config area I configure the nodes for my
paragraph, and the node for my dialog.
Since I stole the paragraphCollections concept from the samples
module, I then add the new paragraph type to a paragraph collection
and I test it out.
When everything for that paragraph module is working the way I want
it to, I export the xml nodes (right click on them) in the admin
interface and get files to drop into my bootstrap directories.
I do the same kind of process for page templates... etc.
At one point, I tried hand-doing the xml files for the dialogs and
the paragraph configurations. The number of nodes in there to
describe the jcr stuff made that a pain, as well as having to
manually deal with UUID stuff... Doing it in the admin interface
and then exporting it is definitely the easiest way I've found.
The 3.5 stuff isn't too much different from the 3.0 stuff - except
for the version handling stuff they threw in there. In my version,
I removed the extra bootstrapping stuff that the samples
VersionHandler was doing (just commented it out) because it was
giving me errors about duplicate UUIDs or some other error (was a
while ago, can't really remember what the problem was - but the
bootstraps there are definitely redundant to the ones I did earlier
in there)
I usually export a few test pages from the website too that I put
in my bootstrap directory to help with development. That way I can
just blow out the entire repository and start from a new version of
the module from scratch and make sure everything is working
properly (i.e. being boostrapped from my files)
If you want to bother with a properties file like they do in the
samples module, you've got to register i18nBasename nodes for
everything that reads from the properties file - and point to the
package / file where the properties file lives. I wouldn't bother -
but I like to do it even though I don't internationalize just so if
soemeone has an issue with how I named or labeled things, they can
just use one file to change it all around rather than sending me
tons of memos and emails telling me to "change what this dialog
says under this box."... that's just a preference thing.
Most of these tips are kind of shorthand, but hopefully they are
helpful to you. Let me know if you need more info.
Ryan
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
