On Jan 17, 2008, at 15:07 , David Smith wrote:
Thanks Greg. I had to read a lot of source code to glean as much
as I did. Any ETA on some much needed official docs w/ respect to
writing modules in version 3.5?
Not really unfortunately. I'm guessing this trimester is enough of a
safe bet, can't promise much more; limited resources and frantic
plannings.
-g
Grégory Joseph wrote:
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
----------------------------------------------------------------
----------------------------------------------------------------
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
----------------------------------------------------------------
