You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by I-Lin Kuo <ik...@hotmail.com> on 2003/10/16 14:32:18 UTC
HTML generator for form post?
I need to submit a form to another site and process the results.
he HTML generator doesn't seem to allow this. Searching around, it seems
StreamGenerator *might* be the way to go, but documentation is sparse. From
my reading, the StreamGenerator requires XML as input, whereas the in my
case the result of a form submission will be html. I'd really want to run it
through jtidy first...
Can anyone who has done this before offer some suggestions? Thanks!
I-Lin Kuo, Ann Arbor, MI
Macromedia Certified ColdFusion 5.0 Advanced Developer
Sun Certified Java 2 Programmer
Ann Arbor Java Users Group (www.aajug.org) SUN Top 25 JUG
_________________________________________________________________
Never get a busy signal because you are always connected with high-speed
Internet access. Click here to comparison-shop providers.
https://broadband.msn.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: HTML generator for form post?
Posted by Oleg Dulin <du...@olegdulin.com>.
You should consider using WebServiceProxyGenerator which does precisely
what you are describing. See
http://wiki.cocoondev.org/Wiki.jsp?page=WebServiceProxyGenerator .
Basically it proxies the http request to a remote site and then pass the
result down the pipeline.
I-Lin Kuo wrote:
> I need to submit a form to another site and process the results.
>
> he HTML generator doesn't seem to allow this. Searching around, it seems
> StreamGenerator *might* be the way to go, but documentation is sparse.
> From my reading, the StreamGenerator requires XML as input, whereas the
> in my case the result of a form submission will be html. I'd really want
> to run it through jtidy first...
>
> Can anyone who has done this before offer some suggestions? Thanks!
>
> I-Lin Kuo, Ann Arbor, MI
> Macromedia Certified ColdFusion 5.0 Advanced Developer
> Sun Certified Java 2 Programmer
> Ann Arbor Java Users Group (www.aajug.org) SUN Top 25 JUG
>
> _________________________________________________________________
> Never get a busy signal because you are always connected with
> high-speed Internet access. Click here to comparison-shop providers.
> https://broadband.msn.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Generator or Logicsheet (or something else)?
Posted by Oleg Dulin <du...@olegdulin.com>.
> 1) Logicsheet. Create a custom logicsheet which wraps calls to the
> existing class library. Then write generators in XSP.
>
> 2) Custom Generators. Code generator(s) which will accept sitemap
> parameters for filtering what data is needed.
>
> 3) Aggregate. Pull in our application data further down the pipeline
>
> Logicsheets seem more flexible, but I'm aware that the API will become
> very extensive over time, and I'm not sure if this approach will scale.
> The concern with aggregating is performance.
Actually what makes sense in applications like this is writing a custom
action in XSP first. Actions give you more flexibility than XSP
generators because they are executed before the pipeline is and they
allow you to process requests before the generators are invoked. But it
is up to you depending on what you need to do.
XSPs scale just fine. You can start with an XSP. As it becomes too
complex, you can inspect the generated code and copy/paste it into a
custom action/generator, etc. and create a custom generator.
Kind regards,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Generator or Logicsheet (or something else)?
Posted by Upayavira <uv...@upaya.co.uk>.
Patrick Dobbs wrote:
>Hi,
>
>I'm working with a standard Java webapp. The business logic is in a
>library of around 300 standard Java classes. There is a management site
>written in JSP. For each customer implementation we then code custom
>pages for our customer's public users (with taglibs). However, we want
>to switch to Cocoon. The plan is to create a high level API in Cocoon to
>make it easier to put together these customised pages by just tweaking
>some XSLTs and juggling sitemap components.
>
>My question is what the best approach to take is. Current ideas include:
>
>1) Logicsheet. Create a custom logicsheet which wraps calls to the
>existing class library. Then write generators in XSP.
>
>2) Custom Generators. Code generator(s) which will accept sitemap
>parameters for filtering what data is needed.
>
>3) Aggregate. Pull in our application data further down the pipeline
>
>Logicsheets seem more flexible, but I'm aware that the API will become
>very extensive over time, and I'm not sure if this approach will scale.
>The concern with aggregating is performance.
>
>Is there a better approach I've missed?
>
>
It depends upon exactly how your site is going to work - whether it is
just presentation, or whether you want to manage the flow between pages
on the basis of results of your java classes. I would suggest either of:
1) If your site is presentation only - a custom generator that accesses
your business logic and passes out SAX events
2) If your site needs to manage flow between pages - use flowscript to
invoke your business logic, and then hand javabeans back to the pipeline
for rendering, using jxtemplategenerator to read data out of the bean to
be placed into the pipeline for presentation.
These seem to me to be the two best approaches. I would find 2) the most
enjoyable/satisfying, but that's not always the best way to judge these
things!
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Generator or Logicsheet (or something else)?
Posted by Ugo Cei <u....@cbim.it>.
Patrick Dobbs wrote:
> My question is what the best approach to take is. Current ideas include:
> 1) Logicsheet. Create a custom logicsheet which wraps calls to the
> 2) Custom Generators. Code generator(s) which will accept sitemap
> 3) Aggregate. Pull in our application data further down the pipeline
> Is there a better approach I've missed?
Flowscript.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Custom Generator or Logicsheet (or something else)?
Posted by Patrick Dobbs <pa...@laculine.com>.
Hi,
I'm working with a standard Java webapp. The business logic is in a
library of around 300 standard Java classes. There is a management site
written in JSP. For each customer implementation we then code custom
pages for our customer's public users (with taglibs). However, we want
to switch to Cocoon. The plan is to create a high level API in Cocoon to
make it easier to put together these customised pages by just tweaking
some XSLTs and juggling sitemap components.
My question is what the best approach to take is. Current ideas include:
1) Logicsheet. Create a custom logicsheet which wraps calls to the
existing class library. Then write generators in XSP.
2) Custom Generators. Code generator(s) which will accept sitemap
parameters for filtering what data is needed.
3) Aggregate. Pull in our application data further down the pipeline
Logicsheets seem more flexible, but I'm aware that the API will become
very extensive over time, and I'm not sure if this approach will scale.
The concern with aggregating is performance.
Is there a better approach I've missed?
Thanks for your consideration.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org