Hi,
here's something where I could start contributing to turbine if you see
the requirements and the idea further below as reasonable.
> From: Jason van Zyl <[EMAIL PROTECTED]>
>
> > Me too! I want to make an XML file then go on vacation! I thought
> > I would start with the DB stuff. But I want to be able to make
> > something like a site descriptor (site.xml) and generate a
> > template for the whole site: actions, layouts, navs, screens,
> > initial content, images ... I only have vague ideas now, but it would be
> > great to have a library of site descriptoras that people can share/use in
> > conjunction with the TDK to pump out an entire site in a few minutes by
> > making some configuration changes.
> >
>
> Frank and myself been looking at exactly what you plan here...
>[snip] I realized that we needed a more flexible solution.
>[snip]
> The basic idea was to use it as a replacement for *OMGenerator, but also to be
>extendable
> to create action and screen .java files (albeit very *basic* ones :-). At the
>moment I
> got it going that it takes JDBCSchemaToDabaseMap and xml definition as input. This
>xml
> definition then determines the out of the file. In other words you can set up this
>xml
> definition file to generate anything from the DatabaseMap data, like peer/map/om
>classes
> but also some basic screen classes.
>[snip]
> ----- end -----
The ideas Leone and Frank are proposing need to be enhanced with other
sources than just input form the DatabaseMap. I guess this is what
Jason and JianHe are trying to get at. Here's my approach to get there:
The requirements:
* templates for actions, layouts, navs, screens, ... as jason wrote
* generic actions via servlets and beans for file, dir, script,
db access
+ These could produce XML output to allow re-formatting (XSLT)
+ Other generic servlets/beans can assist in clipping out the
required parts from the output (e.g. using xpath for XML)
+ the actions may be a combination of one or more method, servlet
or URL calls forming a call-tree
* XML configuration (it could be also less taggy as the TeaServlet
configuration, but this is a matter of taste, and IMHO I believe
we should go XML and not a propietary parser+syntax ->RADable)
+ Similar to cocoon's sitemap, but with the posibility for
several producers/formatter chains to one request
The idea is to interpret the screen/action within a HTTP request,
search the configuration for the action to perform (servlet/bean and
the parameters to take from the HTTP request to it - maybe all).
Note that multiple actions may be chained to produce output
fragments (viewlets). Then finally use the templates to format
what was generated within a predefined layout (the screen).
The XML turbine site configuration could look like:
<turbineSite>
<parameter id="myUrl" value="base/url" \>
...
<screen id="login" template="...">
<action id="login"> <!-- this is run if the user has clicked login -->
<parameter id="body"> <!-- this sets body to the output of bean -->
<action id="loginUrl" bean="stringUtil.catenate">
<parameter id="myUrl" /> <!-- read a paramter value -->
<parameter value="/loginViewlet" \> <!-- anon.constant string -->
</action>
</parameter>
</action>
<action id="logout">
<action bean="session.invalidateSessionUser()" /> <!-- no params -->
<parameter id="body" select="../action[@id='login']/parameter" />
</action
<action id="default"> <!-- default when no action specified -->
<action select="../action[@id='logout']" /> <!-- xpath reference -->
</action>
</screen>
... more screens
</turbineSite>
NOTES:
* the above XMl is just a hack to convey my idea, suggestions are welcome!
* a parameter is set if it has a value or a element body
* a parameter is read if its only referenced or if it contains a
(xpath) select statement - assumes the parameter contains XML nodes.
* a screen is in the sense of turbine, but it is lookued up in the
configuration instead of having a shadow class implementing it
* an action reference is in the sense of turbine, but is looked up
in the configuration.
* an action without a bean or an URL is just a container for
further actions. Actions with beans or URL can take parameters.
* the output of an action may be saved in another parameter or
taken as input paramter to another action.
* parameters, screens, and actions shall be reusable via reference
to existing definitions (e.g. menus, headers, footers).
* maybe the screen level should be removed and let it be a function of the
action.
* the template shall allow laso directly to access the configuration
and contained actions
This latest note hints how the implementation may be done in turbine:
* Use a default template/screen/shadowClass, which executes the turbineSite
actions.
Am I making sense here?
I've done a similar thing with a very generic and powerfull XML
configuration language (existing before, but similar to JDK 1.3 XML
serialization and SOAP XML encoding rules). This should be mapped into
a turbine-site specific syntax (as above). I have used this in a
standalone java application with swing and corba and it works beautifully!
It controls/monitors/operates a big distributed archive and production
system with about 10 targets. More being plugged in every month.
In this new project I'm required to produce a pure browser based
solution interfacing with files/scripts :.( what a step back!
I have up to the end of the year.
Christoph Reck
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
