Ah, I see where you're getting at. Create another
javaflow, register it in the sitemap and let cocoon
take care of it.
I may end up doing that and moving the form code over
to a separate class, but I really don't see much
improvement over simply relocating the big
if...then...else.
The way I was trying to do it was to have an xml
config file that associated a form url with a class.
Then the main javaflow would call the class based on
the request url. The class would then execute the
code that instantiates and shows the form (and does
other stuff specific to the form). I liked this
method because if I needed to add another form, I
could just create a new class and add it to the config
file.
Now I will just have to add another "else" to the main
javaflow, or the "form" javaflow if I decide to use a
secondary flow.
--- Ralph Goers <[EMAIL PROTECTED]> wrote:
> footh wrote:
>
> >Thanks for the reply.
> >
> >I guess that makes sense. I was wondering, is
> there a
> >lot of overhead to loading a bunch of
> >"AbstractContinuable" classes via the
> >ContinuationClassLoader? If so, I might just do it
> >once, or not at all and stick with the
> >if...then...else.
> >
> >
> >
> You are planning on calling the
> ContinuationClassLoader yourself? I
> don't think you really need to do that. If I recall
> correctly the
> classes are only loaded once. But it would be easy
> to check. Just stick
> a System.out.println(this.toString()) in the class
> and see if it changes
> on subsequent requests.
>
> Ralph
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
