cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@dff.st>
Subject RE: Why does Action extend ThreadSafe ?
Date Fri, 10 Aug 2001 16:11:31 GMT
> > > > >> First, about the XSP-action : XSP is a great language to dynamically
> > > > >> generate XML. The purpose of the XSP-action is to be able to
easily
> > > > >> generate XML fragments as part of actions processing (before
generation
> > > > >> starts). We have in our C1 apps a set of form validation and
database
> > > > >> update logicsheets that fit in this area and that I would like
to adapt
> > > > >> to C2.
> > > > >
> > > > >Well, I simply don't understand why you have to generate XML in a
> > > > >Action.
> > > >
> > > > For outputting XML error reports from action-type tags used in the
> > > > XSPAction that get rendered later by the Generator phase?
> > >
> > > That doesn't answer my question. Rendering or marshalling is quite the
> > > same process. So why does it have to be XML? XML is far from being an
> > > ideal representation for inter object communication (Action ->
> > > Generator).
> >
> > Outputting XML is not what is attracting me on XSPActions. (I actually
> > cannot see a good reason for an Action to output XML, too)
> >
> > But using it as a CodeGenerator is neat! Having logicsheets and XSPActions
> > to generate the Actions before they get executed is what I'd like
> > to see...
> 
> Yes, I know as well people get used to XSP for convenience. But I think
> it is quite dangerous to use the XSP MarkupLanguage component as is for
> Actions. It should be a separate MarkupLanguage (as like the sitemap
> has) with a separate xsp.xsl file that prevents dangerous elements like
> <xsp:expr>. That's my point.

It would be nice to have general MarkupLanguageCodeGeneratorComponent that
would get the sitemap.xsl or the xsp.xsl or myAction.xsl as parameter
and will create code from it.

So XSPActions is probably just not the correct term.
--
Torsten

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


Mime
View raw message