cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alberto G." <g__albe...@hotmail.com>
Subject Re: x:forge remarks
Date Mon, 15 Oct 2001 14:26:56 GMT

----- Original Message -----
From: "Neeme Praks" <neeme@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Sunday, October 14, 2001 4:49 AM
Subject: RE: x:forge remarks


>
> > -----Original Message-----
> > From: Alberto G. [mailto:g__alberto@hotmail.com]
> > Sent: Wednesday, October 10, 2001 9:36 AM
> > Subject: Re: x:forge remarks
>
> [...]
>
> > As i said before, i'd like to mantain and improve x:forge and, if the
> > community consider
> > it a possible alternative to XSP, to offer you a full support to
> > understand and modify it.
> >
> > I'll be very happy if the community will help me to improve the code :-)
> >
> > For all of them that hasn't seen it and are interested take a look at
> > http://sourceforge.net/projects/xforge/
> >
> > Please send me any suggest.
>
> Being quite familiar with the XSP, I decided to go and have a look at
> x:forge as well (after so heavy marketing :-) ).
> Some things were not really clear to me and maybe someone can clarify
these:
> From the examples on the website, it seems to me that x:forge is a very
> "simple" system that allows the user to embed a "simple" output to the XML
> page. It lacks more "advanced" logic constructs like loops, conditional
> statements and such, right? So, if the user needs to use such features,
> he/she would need to write such logic inside the toSAX() method of the
> component, right? Meaning that the user has to write the SAX
> event-generation code by hand (or use some utility to generate that part
of
> the code, as it is very error-prone to write that by hand).
>
> So, as much as I understand, instead of mixing Java code with XML (the XSP
> approach), x:forge forces the user to mix XML with Java code (generating
SAX
> events in Java)? Are there any advantages of one over the other (other
than
> taste :-) )?
>
> Sorry, if I misundertood something...
>
> Neeme

You're right, the examples on the website are very simple, probably
it is necessary to put some more complex example, i'll do it soon.

I think making loops, conditional statements and so on, is a matter of Java
not of XML and in a componentized way, just the component has to know what
to do with it's
"input", so the best place to put the logic is the toSax method of the
component.

You're right when you say that's an error writing the SAX event-generation
code by hand, but somewhere it's necessary to do it, for this reason in
x:forge has been
implemented a more elegant way to do it:

There is a specific component named "XForgeMappedComponent" which can be
mapped through an "XForgeComponentMapper" to your classes, this , allows you
to
forget to work in an XML context because the dirty work is done by your
mapper.

I've done a simple implementation of a mapper based on Reflection (it's a
simple implementation),
the idea behind it's to put another abstraction layer between your classes
and the XML generation,
it's just your mapper that knows how your class results have to be
transformed to XML.

Another important feature, is the possibility to share an extendable
variable space between components.
An example: In a multithreading context two components have to share and
modify the same variable just
in their thread context, or suppose the opposite case, where the components
indipendently from the calling
thread, have to share and modify the same variable.
For example you can define a context where to put a counter common to all
components, that lasts for all the jvm life.

In x:forge there is a very simple way to define your own contexts, and put
your variables in that context:
- to define your context just implementing the interface XForgeContext
- to put a variable just calling  putObject( yourContext, aname ,
yourObject ); or by value for Seralizable objects calling
  putVariable( yourContext, aname, serializableObject ).


I hope this helps to understand what is implemented and to know from you
what must be implemented.


Ciao,

Alberto Garoffolo.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message