You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Alberto G." <g_...@hotmail.com> on 2001/10/10 14:18:27 UTC
x:forge remarks
I read in the cocoon mailing list about x:forge valutation and project.
It's a surprise for me read that there is a project to rewrite, totally or
partially, x:forge by Ricardo Rocha.
My position and attention about x:forge is always very strong, indipendently
from the status of Bibop R&D or others enterprise reality. I can assure that
my entusiasm for the project is the same that 6 month ago when i started
writing it, and I would like to partecipate in its evolution and future
projects.
For this reason I ask you to consider my position, opinion and disponibility
for every x:forge project, this for the time, the attention, the projectual
effource i have dedicated to x:forge in its total implementation.
Alberto Garoffolo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: x:forge remarks
Posted by "Alberto G." <g_...@hotmail.com>.
----- Original Message -----
From: "Neeme Praks" <ne...@apache.org>
To: <co...@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
RE: x:forge remarks
Posted by Neeme Praks <ne...@apache.org>.
> -----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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: x:forge remarks
Posted by "Alberto G." <g_...@hotmail.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Wednesday, October 10, 2001 4:29 PM
Subject: Re: x:forge remarks
> "Alberto G." wrote:
> >
> > I read in the cocoon mailing list about x:forge valutation and project.
> >
> > It's a surprise for me read that there is a project to rewrite, totally
or
> > partially, x:forge by Ricardo Rocha.
> >
> > My position and attention about x:forge is always very strong,
indipendently
> > from the status of Bibop R&D or others enterprise reality. I can assure
that
> > my entusiasm for the project is the same that 6 month ago when i started
> > writing it, and I would like to partecipate in its evolution and future
> > projects.
> >
> > For this reason I ask you to consider my position, opinion and
disponibility
> > for every x:forge project, this for the time, the attention, the
projectual
> > effource i have dedicated to x:forge in its total implementation.
>
> Alberto,
>
> thanks for joining us (and sorry for the delay you had in the email,
> there is no filter cospiracy of sort here and there will never be).
>
> For those of you who didn't take a look at the x:forge code, Alberto is
> the author and, for what I can tell, a very good programmer and knower
> of the internals of both Cocoon1, Cocoon2 and Avalon.
>
> Ricardo independently thought about something along the lines of X:Forge
> a long time ago (you knew that) and he is simply moving forward some of
> those ideas in a closed way (something I admittedly don't like, but
> that's the way he works and even if I tried, I can't change his mind on
> this).
>
> As far as post-XSP dynamic XML generation goes, the community will
> decide what to use and will depend on the code, the documentation
> available, the examples to show its power, the vocality of the author on
> the list, his/her ability to reply to user's email and such.
>
> It takes much more than code to build a community.
>
> I'm stating the obvious, I know, but this is to tell you that you should
> not think that we are throwing away x:forge and start again just because
> there are some negative feelings between people on this list about what
> happened in Bibop.
>
> No, I won't let personal interests blind us in technical questions. I
> hope you trust me on this as much as you trusted me on other questions.
>
> To be honest, I thought about moving x:forge over into the Cocoon HEAD
> CVS branch both to move forward and to push Ricardo, but I was afraid of
> the "black box" effect where unmaintained code goes into the
> distribution and nobody really knows what's going on.
>
> Your active presence on this list will automatically remove my concerns.
>
> Please understand this is a general thing and it's not related by you
> nor x:forge: I'm more concerned about community that code because a good
> community creates good code, but good code doesn't automatically create
> good communities.
>
> In fact, the XSP engine and Ricardo's spotty presence happen to have the
> same situation.
>
> As well as current discussions about the SQL part with Donald away for
> some time.
>
> The community will vote whether to accept x:forge or Ricardo's DXML in
> the distribution, but more than accepting blackbox contributions, I'd
> love to see development taking place internally.
>
> And this is a warning to Ricardo as well.
>
> I will personally reject code donations unless backed up with
> documentation, samples, and, more important, a more or less guaranteed
> presence on the mail lists of the original author and maintainer.
>
> I hope this clarifies the issues on this and shows you the transparency
> you were expecting on the cocoon-dev mail list.
>
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.
Ciao,
Alberto Garoffolo.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: x:forge remarks
Posted by Stefano Mazzocchi <st...@apache.org>.
"Alberto G." wrote:
>
> I read in the cocoon mailing list about x:forge valutation and project.
>
> It's a surprise for me read that there is a project to rewrite, totally or
> partially, x:forge by Ricardo Rocha.
>
> My position and attention about x:forge is always very strong, indipendently
> from the status of Bibop R&D or others enterprise reality. I can assure that
> my entusiasm for the project is the same that 6 month ago when i started
> writing it, and I would like to partecipate in its evolution and future
> projects.
>
> For this reason I ask you to consider my position, opinion and disponibility
> for every x:forge project, this for the time, the attention, the projectual
> effource i have dedicated to x:forge in its total implementation.
Alberto,
thanks for joining us (and sorry for the delay you had in the email,
there is no filter cospiracy of sort here and there will never be).
For those of you who didn't take a look at the x:forge code, Alberto is
the author and, for what I can tell, a very good programmer and knower
of the internals of both Cocoon1, Cocoon2 and Avalon.
Ricardo independently thought about something along the lines of X:Forge
a long time ago (you knew that) and he is simply moving forward some of
those ideas in a closed way (something I admittedly don't like, but
that's the way he works and even if I tried, I can't change his mind on
this).
As far as post-XSP dynamic XML generation goes, the community will
decide what to use and will depend on the code, the documentation
available, the examples to show its power, the vocality of the author on
the list, his/her ability to reply to user's email and such.
It takes much more than code to build a community.
I'm stating the obvious, I know, but this is to tell you that you should
not think that we are throwing away x:forge and start again just because
there are some negative feelings between people on this list about what
happened in Bibop.
No, I won't let personal interests blind us in technical questions. I
hope you trust me on this as much as you trusted me on other questions.
To be honest, I thought about moving x:forge over into the Cocoon HEAD
CVS branch both to move forward and to push Ricardo, but I was afraid of
the "black box" effect where unmaintained code goes into the
distribution and nobody really knows what's going on.
Your active presence on this list will automatically remove my concerns.
Please understand this is a general thing and it's not related by you
nor x:forge: I'm more concerned about community that code because a good
community creates good code, but good code doesn't automatically create
good communities.
In fact, the XSP engine and Ricardo's spotty presence happen to have the
same situation.
As well as current discussions about the SQL part with Donald away for
some time.
The community will vote whether to accept x:forge or Ricardo's DXML in
the distribution, but more than accepting blackbox contributions, I'd
love to see development taking place internally.
And this is a warning to Ricardo as well.
I will personally reject code donations unless backed up with
documentation, samples, and, more important, a more or less guaranteed
presence on the mail lists of the original author and maintainer.
I hope this clarifies the issues on this and shows you the transparency
you were expecting on the cocoon-dev mail list.
Ciao.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org