Hi Paul,
Yes, we also develop our own modules. One of our modules exists only to supply
model-classes, but that's not the only way to structure it - in theory the
model classes can reside in any JAR on magnolia's classpath.
The model-classes are tied to the template-definitions (or areas, or
components). When creating your template-definitions, you can specify a
"modelClass" property, which identifies a Java class (by fully qualified name).
This class is automatically instantiated and initialized by magnolia whenever
your template (or area, or component) is rendered.
The model-class can supply additional functionality and data to the template,
basically whenever freemarker is "not enough" or cumbersome, you can put that
functionality in your model-class and thereby implement it in Java (or Groovy,
if you want) instead of freemarker. The instantiated model-class is availabile
from freemarker using the variable "model". Try outputting ${model.class.name}
in any template script, for example.
Like the templates, areas and components, the model-classes form a hierarchy
during rendering. So a component will have a model, and that model will have a
parent model, which is the model of the area. And the area's model will have
the page's model as a parent...
Model-Classes should inherit from
"info.magnolia.rendering.model.RenderingModelImpl", or even better
"info.magnolia.module.templatingkit.templates.pages.STKPageModel" (for pages)
and "info.magnolia.module.templatingkit.templates.AbstractSTKTemplateModel"
(for components).
Blossom is a different way of working, and I have no experience with that -
others on this list might be able to help you more with Blossom...
I believe Blossom allows you to define your templates and components
programmatically, but really I am not sure how that all works.
If you decide not to use Blossom, you can still pack your template- and
component-definitions into your own module, and install (or upgrade) them using
magnolia's powerful module bootstrapping mechanism.
What you describe makes sense, but I caution that it is a stateful model,
requiring you to maintain a session on the magnolia server which holds the data
you loaded for the user after login. In principle, a stateful model is fine,
but it does come with scalability problems (lots of sessions means lots of RAM
used, and sessions make clustering the public servers harder).
Regards from Vienna,
Richard
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]]
Im Auftrag von Paul Shuttlewood (via Magnolia Forums)
Gesendet: Dienstag, 31. Juli 2012 12:19
An: Magnolia User List
Betreff: [magnolia-user] Re: How to design Magnolia to retrieve/set external
data
Hi Richard,
Thanks for the detailed reply, it's certainly given me some pointers to look
into.
Can I ask what you mean by "We then create one or more magnolia
"Model-Classes""? I'm expecting to develop a magnolia module which will contain
a new basic POJO model, an interface wrapper layer to my web services and of
course my template definitions (in Freemarker as opposed to JSP is my
preference). I'm looking at the Magnolia Blossom samples and this I think will
give me that. What module/API are you developing to?
Ideally I want to deliver components and area definitions in my module, and
allow content definers to create their pages and choose where they place my
components/areas on their page. I also need to consider how different clients
may want to render the POJO model differently.
My initial idea is that upon login, I will retrieve the complete POJO model for
that person (i.e. make all retrieve web service calls). So as the user
nagivates the different pages, I just access the different sections of the POJO
model. I will only make a web service call if the user updates some part of the
model or I need to refresh.
Regards,
Paul
--
Context is everything:
http://forum.magnolia-cms.com/forum/thread.html?threadId=2e16ec5c-2be3-4d9a-b79d-f6df9f2bc0bd
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
