You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Lewis, Andrew J" <An...@jbosc.ksc.nasa.gov> on 2002/05/10 00:58:49 UTC
A Transformer in progress....
> I'm working on a Transformer that processes specifically text nodes and
> using regular expressions, wraps matched portions of a node in a tag. I'm
> really just getting started on it - I have the basics working, but still
> need to be able to specify the rules in an external file, etc. It has been
> an interesting excercise so far, and the intent is to be able to detect
> things like dates, currency amounts, and units of measure in a text node,
> and mark them for later processing.
>
> I am planning on allowing rules to be specified in an external file
> identified at componenet configuration, or directly in the component
> configuration. I am also planning on allowing the "replacement" to be a
> complete fragement with groups from the matched expression referencable
> (and replaced) in etiher attribute values or text nodes. (currently I
> merely enclose the match in a tag).
>
> Before I move on, has anyone else already done something like this? Does
> anyone (other than me) think it would be useful?
>
> Ok...now to my real question...
>
> Does anyone know of existing code that I can use to track and identify if
> the current point in the SAX stream matches a simplified XPath expression?
> I would really like to apply expression rule set based on an XPath subset.
>
> Any comments or suggestions?
>
> Thanks!
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A Transformer in progress....
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
> "Lewis, Andrew J" wrote:
> >
> > > I'm working on a Transformer that processes specifically text nodes
and
> > > using regular expressions, wraps matched portions of a node in a tag.
I'm
> > > really just getting started on it - I have the basics working, but
still
> > > need to be able to specify the rules in an external file, etc. It has
been
> > > an interesting excercise so far, and the intent is to be able to
detect
> > > things like dates, currency amounts, and units of measure in a text
node,
> > > and mark them for later processing.
> > >
> > > I am planning on allowing rules to be specified in an external file
> > > identified at componenet configuration, or directly in the component
> > > configuration. I am also planning on allowing the "replacement" to be
a
> > > complete fragement with groups from the matched expression
referencable
> > > (and replaced) in etiher attribute values or text nodes. (currently I
> > > merely enclose the match in a tag).
> > >
> > > Before I move on, has anyone else already done something like this?
Does
> > > anyone (other than me) think it would be useful?
> > >
> > > Ok...now to my real question...
> > >
> > > Does anyone know of existing code that I can use to track and identify
if
> > > the current point in the SAX stream matches a simplified XPath
expression?
> > > I would really like to apply expression rule set based on an XPath
subset.
> > >
> > > Any comments or suggestions?
> > >
> > > Thanks!
>
> I know that Simon wrote a SAX filter along the lines of this, right
> Simon?
>
> I think it's going to be piece of cake to take his stuff and make it a
> cocoon transformer.
There is a Transformer (currently broken :-( ) in the scratchpad that tried
to do something along these lines. It worked in an early Cocoon Alpha
release, and quick attempts to have it working again weren't sufficient.
Look at Chart2SvgTransformer.java in scratchpad.
It's there waiting for:
1 someone to fix it
2 someone to write something better
Which means.... that I can't wait to use your Transformer instead! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Request
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Artur Bialecki" <ar...@digitalfairway.com>
> > -----Original Message-----
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > >
> > >
> > > It would be nice if there was an easy way to convert
> > > HttpServletRequest to HttpRequest, HttpServletResponse to
> > > HttpResponse, etc.
> > >
> > > Right now I can't see any easy way of doing this.
> > > Maybe new constructors or static conversion methods
> > > that do this would be very useful.
> > >
> > > What do you think ?
> >
> > Why this would be needed?
> >
>
> If you start a new cocoon project and you're _not_ using
> other libraries that already _extend/return_ HttpServletRequest
> and others than you probably don't need it.
>
> But, if you have some request/response/cookie processing
> libraries which were used in Cocoon1 or your JSP site
> and you're moving to Cocoon2 and want to use these
> from XSP, etc. you either have to rewire (If you can)
> your libraries to use cocoon's Request, Response, etc.
> or preform the conversion in some easy way. Since the
> first option may not allways be feasable.
>
> IMHO adding such conversion functionality would only improve
> cocoon.
I second this need.
80% of "how can I..." questions I has was "How can I use HttpXXX interface
instead of Cocoon ones?".
There are tons of libraries written to those interfaces.
Anyone volunteering?
Come on, it shouldn't be too hard ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Request
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Artur Bialecki" <ar...@digitalfairway.com>
>
> > Don't you think this will bring new wave of discussions "Cocoon Request
> > vs HTTP Request"?
> >
> >
> > Vadim
> >
>
> I wasn't part of the previous discussions but having nice conversion
> methods might put an end to future discussions on this topic.
> I can see the benefit of Cocoon having its own Request, Response, etc.
> but sometimes you just can't use them. So and anwser might be:
> "If you don't like or want to use Cocoon's request just convert it."
+1
If we provide the original HTTP* objects, they say: "hey, why don't you use
that?", and will have trouble in converting the Http only libraries to work
in other environments.
If we have a conversion class, you have a cleaner and simpler upgrade path
to using Cocoon's version.
Not that I will write it myself ;-)
Artur, if you write it I will commit it, if there are no -1s of course.
I would also like to discourage the use of underlying original
implementations, since it really brakes the system.
It's like making a variable that has get-set accessors public.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Artur Bialecki <ar...@digitalfairway.com>.
> Don't you think this will bring new wave of discussions "Cocoon Request
> vs HTTP Request"?
>
>
> Vadim
>
I wasn't part of the previous discussions but having nice conversion
methods might put an end to future discussions on this topic.
I can see the benefit of Cocoon having its own Request, Response, etc.
but sometimes you just can't use them. So and anwser might be:
"If you don't like or want to use Cocoon's request just convert it."
Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> From: "Vadim Gritsenko" <va...@verizon.net>
>
> > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > >
> > > > -----Original Message-----
> > > > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > > > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > > > >
> > > > >
> > > > > It would be nice if there was an easy way to convert
> > > > > HttpServletRequest to HttpRequest, HttpServletResponse to
> > > > > HttpResponse, etc.
> > > > >
> > > > > Right now I can't see any easy way of doing this.
> > > > > Maybe new constructors or static conversion methods
> > > > > that do this would be very useful.
> > > > >
> > > > > What do you think ?
> > > >
> > > > Why this would be needed?
> > > >
> > >
> > > If you start a new cocoon project and you're _not_ using
> > > other libraries that already _extend/return_ HttpServletRequest
> > > and others than you probably don't need it.
> > >
> > > But, if you have some request/response/cookie processing
> > > libraries which were used in Cocoon1 or your JSP site
> > > and you're moving to Cocoon2 and want to use these
> > > from XSP, etc. you either have to rewire (If you can)
> > > your libraries to use cocoon's Request, Response, etc.
> > > or preform the conversion in some easy way. Since the
> > > first option may not allways be feasable.
> >
> > Do you know that Http* objects *are* *already* available in Cocoon?
> > Hence my question: why do you need wrappers if you can use original
> > Http* objects?
> >
> > PS See PhpGenerator
> >
> > PPS Bear in mind that Http* objects available only in HTTP
environment.
>
> Which is a hack IMO.
> If the Cocoon env interface is all one needs, why have the original
HTTP one
> available.
>
> It's a *big* hole in the env facade.
I say it's tradeoff to allow easy migration of HTTP-only-oriented apps
to Cocoon 2.
> However, if you make a conversion class, the facade still stands...
Don't you think this will bring new wave of discussions "Cocoon Request
vs HTTP Request"?
Vadim
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Request
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Vadim Gritsenko" <va...@verizon.net>
> > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> >
> > > -----Original Message-----
> > > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > > >
> > > >
> > > > It would be nice if there was an easy way to convert
> > > > HttpServletRequest to HttpRequest, HttpServletResponse to
> > > > HttpResponse, etc.
> > > >
> > > > Right now I can't see any easy way of doing this.
> > > > Maybe new constructors or static conversion methods
> > > > that do this would be very useful.
> > > >
> > > > What do you think ?
> > >
> > > Why this would be needed?
> > >
> >
> > If you start a new cocoon project and you're _not_ using
> > other libraries that already _extend/return_ HttpServletRequest
> > and others than you probably don't need it.
> >
> > But, if you have some request/response/cookie processing
> > libraries which were used in Cocoon1 or your JSP site
> > and you're moving to Cocoon2 and want to use these
> > from XSP, etc. you either have to rewire (If you can)
> > your libraries to use cocoon's Request, Response, etc.
> > or preform the conversion in some easy way. Since the
> > first option may not allways be feasable.
>
> Do you know that Http* objects *are* *already* available in Cocoon?
> Hence my question: why do you need wrappers if you can use original
> Http* objects?
>
> PS See PhpGenerator
>
> PPS Bear in mind that Http* objects available only in HTTP environment.
Which is a hack IMO.
If the Cocoon env interface is all one needs, why have the original HTTP one
available.
It's a *big* hole in the env facade.
However, if you make a conversion class, the facade still stands...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Artur Bialecki <ar...@digitalfairway.com>.
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
<snip>
>
> There's already such an adapter in DeliImpl, along with a ServletContext
> adapter. We should move them to environment.http so they have a better
> visibility.
The DeliImpl only wraps Request, the CocoonServletContext
doesn't implement cocoon's Context or HttpContext.
We need conversion for all cocoon's Context, Cookie, Request,
Response, Session. What would be the best way to do this?
1. public constructors that take javax.servlet.* interfaces
in all Cocoon's ...environment.http.Http* classes.
2. public static convert() or from/to() methods on all
...environment.http.Http* classes.
3. public static convert() or from/to() method for on
HttpEnvironment class for each Http* type.
4. provide wrapper class for each ...environment.http.Http*
that implements it's equivalent javax.servlet.* class.
5. other ???
What fits best the current Cocoon model?
Personally, I would like to see something that works nicely
in both directions. The current way of getting the original
request object is not very pretty.
What do you think?
Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Request
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Artur Bialecki [mailto:artur@digitalfairway.com]
>>
>>
>>>-----Original Message-----
>>>From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>>>Sent: Monday, May 13, 2002 10:31 AM
>>>To: cocoon-dev@xml.apache.org
>>>Subject: RE: Request
>>>
>>>
>>>>From: Artur Bialecki [mailto:artur@digitalfairway.com]
>>>>
>>>>>-----Original Message-----
>>>>>From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>>>>>
>>>>>>From: Artur Bialecki [mailto:artur@digitalfairway.com]
>>>>>>
>>>>>>
>>>>>>It would be nice if there was an easy way to convert
>>>>>>HttpServletRequest to HttpRequest, HttpServletResponse to
>>>>>>HttpResponse, etc.
>>>>>>
>>>>>>Right now I can't see any easy way of doing this.
>>>>>>Maybe new constructors or static conversion methods
>>>>>>that do this would be very useful.
>>>>>>
>>>>>>What do you think ?
>>>>>>
>>>>>Why this would be needed?
>>>>>
>>>>If you start a new cocoon project and you're _not_ using
>>>>other libraries that already _extend/return_ HttpServletRequest
>>>>and others than you probably don't need it.
>>>>
>>>>But, if you have some request/response/cookie processing
>>>>libraries which were used in Cocoon1 or your JSP site
>>>>and you're moving to Cocoon2 and want to use these
>>>>from XSP, etc. you either have to rewire (If you can)
>>>>your libraries to use cocoon's Request, Response, etc.
>>>>or preform the conversion in some easy way. Since the
>>>>first option may not allways be feasable.
>>>>
>>>Do you know that Http* objects *are* *already* available in Cocoon?
>>>Hence my question: why do you need wrappers if you can use original
>>>Http* objects?
>>>
>>I know that you can
>>
>objectModel.get(HttpEnvironment.HTTP_REQUEST_OBJECT)
>
>>but that only solves passing requests/responses/cookies into library
>>methods. But when methods return/extend HttpServletRequest (etc.) I
>>
>can't
>
>>do the following in my XSPs or logicsheets:
>><xsp:logic>
>> request = new SuperRequest(request);
>> //or
>> request = UberHttpLib.getUberRequest(request);
>></xsp:logic>
>>
>>if the SuperRequest extends HttpServletRequest
>>or the getUberRequest returns HttpServletRequest.
>>
>
>Ok, that's good enough reason to have wrapper/converter.
>
There's already such an adapter in DeliImpl, along with a ServletContext
adapter. We should move them to environment.http so they have a better
visibility.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Artur Bialecki [mailto:artur@digitalfairway.com]
>
>
> > -----Original Message-----
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > Sent: Monday, May 13, 2002 10:31 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: RE: Request
> >
> >
> > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > >
> > > > -----Original Message-----
> > > > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > > > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > > > >
> > > > >
> > > > > It would be nice if there was an easy way to convert
> > > > > HttpServletRequest to HttpRequest, HttpServletResponse to
> > > > > HttpResponse, etc.
> > > > >
> > > > > Right now I can't see any easy way of doing this.
> > > > > Maybe new constructors or static conversion methods
> > > > > that do this would be very useful.
> > > > >
> > > > > What do you think ?
> > > >
> > > > Why this would be needed?
> > > >
> > >
> > > If you start a new cocoon project and you're _not_ using
> > > other libraries that already _extend/return_ HttpServletRequest
> > > and others than you probably don't need it.
> > >
> > > But, if you have some request/response/cookie processing
> > > libraries which were used in Cocoon1 or your JSP site
> > > and you're moving to Cocoon2 and want to use these
> > > from XSP, etc. you either have to rewire (If you can)
> > > your libraries to use cocoon's Request, Response, etc.
> > > or preform the conversion in some easy way. Since the
> > > first option may not allways be feasable.
> >
> > Do you know that Http* objects *are* *already* available in Cocoon?
> > Hence my question: why do you need wrappers if you can use original
> > Http* objects?
> >
>
> I know that you can
objectModel.get(HttpEnvironment.HTTP_REQUEST_OBJECT)
> but that only solves passing requests/responses/cookies into library
> methods. But when methods return/extend HttpServletRequest (etc.) I
can't
> do the following in my XSPs or logicsheets:
> <xsp:logic>
> request = new SuperRequest(request);
> //or
> request = UberHttpLib.getUberRequest(request);
> </xsp:logic>
>
> if the SuperRequest extends HttpServletRequest
> or the getUberRequest returns HttpServletRequest.
Ok, that's good enough reason to have wrapper/converter.
Vadim
> Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Artur Bialecki <ar...@digitalfairway.com>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Monday, May 13, 2002 10:31 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: Request
>
>
> > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> >
> > > -----Original Message-----
> > > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > > >
> > > >
> > > > It would be nice if there was an easy way to convert
> > > > HttpServletRequest to HttpRequest, HttpServletResponse to
> > > > HttpResponse, etc.
> > > >
> > > > Right now I can't see any easy way of doing this.
> > > > Maybe new constructors or static conversion methods
> > > > that do this would be very useful.
> > > >
> > > > What do you think ?
> > >
> > > Why this would be needed?
> > >
> >
> > If you start a new cocoon project and you're _not_ using
> > other libraries that already _extend/return_ HttpServletRequest
> > and others than you probably don't need it.
> >
> > But, if you have some request/response/cookie processing
> > libraries which were used in Cocoon1 or your JSP site
> > and you're moving to Cocoon2 and want to use these
> > from XSP, etc. you either have to rewire (If you can)
> > your libraries to use cocoon's Request, Response, etc.
> > or preform the conversion in some easy way. Since the
> > first option may not allways be feasable.
>
> Do you know that Http* objects *are* *already* available in Cocoon?
> Hence my question: why do you need wrappers if you can use original
> Http* objects?
>
I know that you can objectModel.get(HttpEnvironment.HTTP_REQUEST_OBJECT)
but that only solves passing requests/responses/cookies into library
methods. But when methods return/extend HttpServletRequest (etc.) I can't
do the following in my XSPs or logicsheets:
<xsp:logic>
request = new SuperRequest(request);
//or
request = UberHttpLib.getUberRequest(request);
</xsp:logic>
if the SuperRequest extends HttpServletRequest
or the getUberRequest returns HttpServletRequest.
Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Artur Bialecki [mailto:artur@digitalfairway.com]
>
> > -----Original Message-----
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> > >
> > >
> > > It would be nice if there was an easy way to convert
> > > HttpServletRequest to HttpRequest, HttpServletResponse to
> > > HttpResponse, etc.
> > >
> > > Right now I can't see any easy way of doing this.
> > > Maybe new constructors or static conversion methods
> > > that do this would be very useful.
> > >
> > > What do you think ?
> >
> > Why this would be needed?
> >
>
> If you start a new cocoon project and you're _not_ using
> other libraries that already _extend/return_ HttpServletRequest
> and others than you probably don't need it.
>
> But, if you have some request/response/cookie processing
> libraries which were used in Cocoon1 or your JSP site
> and you're moving to Cocoon2 and want to use these
> from XSP, etc. you either have to rewire (If you can)
> your libraries to use cocoon's Request, Response, etc.
> or preform the conversion in some easy way. Since the
> first option may not allways be feasable.
Do you know that Http* objects *are* *already* available in Cocoon?
Hence my question: why do you need wrappers if you can use original
Http* objects?
PS See PhpGenerator
PPS Bear in mind that Http* objects available only in HTTP environment.
Vadim
> IMHO adding such conversion functionality would only improve
> cocoon.
>
>
> Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Artur Bialecki <ar...@digitalfairway.com>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> >
> >
> > It would be nice if there was an easy way to convert
> > HttpServletRequest to HttpRequest, HttpServletResponse to
> > HttpResponse, etc.
> >
> > Right now I can't see any easy way of doing this.
> > Maybe new constructors or static conversion methods
> > that do this would be very useful.
> >
> > What do you think ?
>
> Why this would be needed?
>
If you start a new cocoon project and you're _not_ using
other libraries that already _extend/return_ HttpServletRequest
and others than you probably don't need it.
But, if you have some request/response/cookie processing
libraries which were used in Cocoon1 or your JSP site
and you're moving to Cocoon2 and want to use these
from XSP, etc. you either have to rewire (If you can)
your libraries to use cocoon's Request, Response, etc.
or preform the conversion in some easy way. Since the
first option may not allways be feasable.
IMHO adding such conversion functionality would only improve
cocoon.
Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Request
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Artur Bialecki [mailto:artur@digitalfairway.com]
>
>
> It would be nice if there was an easy way to convert
> HttpServletRequest to HttpRequest, HttpServletResponse to
> HttpResponse, etc.
>
> Right now I can't see any easy way of doing this.
> Maybe new constructors or static conversion methods
> that do this would be very useful.
>
> What do you think ?
Why this would be needed?
Vadim
>
> Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Request
Posted by Artur Bialecki <ar...@digitalfairway.com>.
It would be nice if there was an easy way to convert
HttpServletRequest to HttpRequest, HttpServletResponse to
HttpResponse, etc.
Right now I can't see any easy way of doing this.
Maybe new constructors or static conversion methods
that do this would be very useful.
What do you think ?
Artur...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A Transformer in progress....
Posted by "Simon St.Laurent" <si...@oreilly.com>.
Regular Fragmentations does _most_ of this:
http://regfrag.sourceforge.net/
The rules vocabulary is described at:
http://simonstl.com/ns/fragments/
The one key pieces that's missing is the XPath support, which I've been
planning for a while but haven't gotten to building. I've been building a
new and more flexible object model (http://moe.sourceforge.net/) to use
with RegFrag, but hopefully...
At 02:10 PM 5/10/2002 +0200, Stefano Mazzocchi wrote:
>"Lewis, Andrew J" wrote:
> >
> > > I'm working on a Transformer that processes specifically text nodes and
> > > using regular expressions, wraps matched portions of a node in a tag. I'm
> > > really just getting started on it - I have the basics working, but still
> > > need to be able to specify the rules in an external file, etc. It has
> been
> > > an interesting excercise so far, and the intent is to be able to detect
> > > things like dates, currency amounts, and units of measure in a text node,
> > > and mark them for later processing.
> > >
> > > I am planning on allowing rules to be specified in an external file
> > > identified at componenet configuration, or directly in the component
> > > configuration. I am also planning on allowing the "replacement" to be a
> > > complete fragement with groups from the matched expression referencable
> > > (and replaced) in etiher attribute values or text nodes. (currently I
> > > merely enclose the match in a tag).
> > >
> > > Before I move on, has anyone else already done something like this? Does
> > > anyone (other than me) think it would be useful?
> > >
> > > Ok...now to my real question...
> > >
> > > Does anyone know of existing code that I can use to track and identify if
> > > the current point in the SAX stream matches a simplified XPath
> expression?
> > > I would really like to apply expression rule set based on an XPath
> subset.
> > >
> > > Any comments or suggestions?
> > >
> > > Thanks!
>
>I know that Simon wrote a SAX filter along the lines of this, right
>Simon?
>
>I think it's going to be piece of cake to take his stuff and make it a
>cocoon transformer.
>
>--
>Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
><st...@apache.org> Friedrich Nietzsche
>--------------------------------------------------------------------
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
Simon St.Laurent
Associate Editor
O'Reilly & Associates, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A Transformer in progress....
Posted by Stefano Mazzocchi <st...@apache.org>.
"Lewis, Andrew J" wrote:
>
> > I'm working on a Transformer that processes specifically text nodes and
> > using regular expressions, wraps matched portions of a node in a tag. I'm
> > really just getting started on it - I have the basics working, but still
> > need to be able to specify the rules in an external file, etc. It has been
> > an interesting excercise so far, and the intent is to be able to detect
> > things like dates, currency amounts, and units of measure in a text node,
> > and mark them for later processing.
> >
> > I am planning on allowing rules to be specified in an external file
> > identified at componenet configuration, or directly in the component
> > configuration. I am also planning on allowing the "replacement" to be a
> > complete fragement with groups from the matched expression referencable
> > (and replaced) in etiher attribute values or text nodes. (currently I
> > merely enclose the match in a tag).
> >
> > Before I move on, has anyone else already done something like this? Does
> > anyone (other than me) think it would be useful?
> >
> > Ok...now to my real question...
> >
> > Does anyone know of existing code that I can use to track and identify if
> > the current point in the SAX stream matches a simplified XPath expression?
> > I would really like to apply expression rule set based on an XPath subset.
> >
> > Any comments or suggestions?
> >
> > Thanks!
I know that Simon wrote a SAX filter along the lines of this, right
Simon?
I think it's going to be piece of cake to take his stuff and make it a
cocoon transformer.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A Transformer in progress....
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Lewis, Andrew J wrote:
>
>>I'm working on a Transformer that processes specifically text nodes and
>>using regular expressions, wraps matched portions of a node in a tag. I'm
>>really just getting started on it - I have the basics working, but still
>>need to be able to specify the rules in an external file, etc. It has been
>>an interesting excercise so far, and the intent is to be able to detect
>>things like dates, currency amounts, and units of measure in a text node,
>>and mark them for later processing.
>>
>>I am planning on allowing rules to be specified in an external file
>>identified at componenet configuration, or directly in the component
>>configuration. I am also planning on allowing the "replacement" to be a
>>complete fragement with groups from the matched expression referencable
>>(and replaced) in etiher attribute values or text nodes. (currently I
>>merely enclose the match in a tag).
>>
>>Before I move on, has anyone else already done something like this? Does
>>anyone (other than me) think it would be useful?
>>
>>Ok...now to my real question...
>>
>>Does anyone know of existing code that I can use to track and identify if
>>the current point in the SAX stream matches a simplified XPath expression?
>>I would really like to apply expression rule set based on an XPath subset.
>>
>>Any comments or suggestions?
>>
For the simplified XPath, you should take a look a the ongoing work on
STX (streaming transformations for XML) at
http://www.gingerall.cz/stx/index.html : they have defined a subset of
XPath compatible with event-driven transformations.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: A Transformer in progress....
Posted by Ivelin Ivanov <iv...@apache.org>.
Did you look at Jakarta Digester?
http://jakarta.apache.org/commons/digester.html
----- Original Message -----
From: "Lewis, Andrew J" <An...@jbosc.ksc.nasa.gov>
To: <co...@xml.apache.org>
Sent: Thursday, May 09, 2002 5:58 PM
Subject: A Transformer in progress....
>
>
> > I'm working on a Transformer that processes specifically text nodes and
> > using regular expressions, wraps matched portions of a node in a tag.
I'm
> > really just getting started on it - I have the basics working, but still
> > need to be able to specify the rules in an external file, etc. It has
been
> > an interesting excercise so far, and the intent is to be able to detect
> > things like dates, currency amounts, and units of measure in a text
node,
> > and mark them for later processing.
> >
> > I am planning on allowing rules to be specified in an external file
> > identified at componenet configuration, or directly in the component
> > configuration. I am also planning on allowing the "replacement" to be a
> > complete fragement with groups from the matched expression referencable
> > (and replaced) in etiher attribute values or text nodes. (currently I
> > merely enclose the match in a tag).
> >
> > Before I move on, has anyone else already done something like this? Does
> > anyone (other than me) think it would be useful?
> >
> > Ok...now to my real question...
> >
> > Does anyone know of existing code that I can use to track and identify
if
> > the current point in the SAX stream matches a simplified XPath
expression?
> > I would really like to apply expression rule set based on an XPath
subset.
> >
> > Any comments or suggestions?
> >
> > Thanks!
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: A Transformer in progress....
Posted by Marc Portier <mp...@outerthought.org>.
> > I'm working on a Transformer that processes specifically text nodes and
> > using regular expressions, wraps matched portions of a node in
> a tag. I'm
> > really just getting started on it - I have the basics working, but still
> > need to be able to specify the rules in an external file, etc.
> It has been
> > an interesting excercise so far, and the intent is to be able to detect
> > things like dates, currency amounts, and units of measure in a
> text node,
> > and mark them for later processing.
> >
> > I am planning on allowing rules to be specified in an external file
> > identified at componenet configuration, or directly in the component
> > configuration. I am also planning on allowing the "replacement" to be a
> > complete fragement with groups from the matched expression referencable
> > (and replaced) in etiher attribute values or text nodes. (currently I
> > merely enclose the match in a tag).
> >
> > Before I move on, has anyone else already done something like this? Does
> > anyone (other than me) think it would be useful?
> >
did something similar around january, after that the interest/needs kinda
shifted,
so I didn't continu on it since, I still plan on taking it up round the
summer or so
(if you want I can make my current stuff available, and join in some
discussions)
the biggest difference however is that you're assuming input has good but
too little markup
(so you go for a transformer)
while we were scratching the itch of pure text input and/or bad markup
present
(like HTML that jTidy can't handle, or even now when there is nekoHTML:
whenever the
regex approach is easier then the XSLT afterwards cause of the mess in the
HTML)
(so we chose a generator as lifeform)
at the time we started we colided with some joint thinking activity about
adding
regex kind of support inside XSLT2.0, see for some of those discussions:
http://www.biglist.com/lists/xsl-list/archives/200201/msg00488.html
must say, I didn't follow the further development of xslt2.0 since, so maybe
someone else
could comment on any future for this kind of stuff inside the spec (and thus
impls like
xalan or saxon)
> > Ok...now to my real question...
> >
> > Does anyone know of existing code that I can use to track and
> identify if
> > the current point in the SAX stream matches a simplified XPath
> expression?
> > I would really like to apply expression rule set based on an
> XPath subset.
Elas, don't know of such a beast (would be nice though)
So you got me triggered about thinking about this :-)
Can we define 'Simplified' xpath ?
SAX gives you a timely snapshot of current position in the XML file
so you would easily be able to have some kind of match for a simple
hierarchy of elements (wouldn't even need to be root based I guess,
even slide in some attribute tests should be possible, also position
evaluation as long as it's not =last()... )
SAX just doesn't allow to look into the future so a lot of xpath you
will not be able to do.
> >
> > Any comments or suggestions?
You'll have to take a trade-off between how far you can cripple xpath to
still
support your needs, yet still can beat the maybe awkward but not totally
wrong
approch of building a temp DOM tree internally in your cocoon transformer to
allow real xpath stuff upon? (after all something similar happens to some
extend
inside the xslt process he)
> >
> > Thanks!
please keep us posted of your findings and progress
-marc=
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org