Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-11 Thread Josema Alonso 
 Just open org.apache.cocoon.samples.xmlform.WizardAction.java
 then look more carefully in webapp/samples/xmlform

I did but haven't found anything new...any tips?
I see in the sitemap the WizardAction and the UsageFeedbackAction declared
and a hardcoded pipeline for each one. I would not like to hardcode dozens
of pipelines for everyone of my forms...I'll try any of the suggestions you
gave me when I have some time. Thanks.




-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-09 Thread Josema Alonso 
 I am not sure if I would do this like you did.
 There are is a certain lifecycle contract between every Cocoon component
and
 the container.
 By invoking directly you may be violating this contract.
 I would probably let the sitemap do the forwarding to actions.
 In your case action sets might be good.
 http://xml.apache.org/cocoon/userdocs/concepts/actions.html
I considered them and maybe I'll use them. I'm trying to make a good
decision.

 Alternatively you can use one dispatcher action which inherits from
 AbstractXMLFormAction and works directly with the backend based on the
 requested command.
I see. Someone pointed this one, too, but I'm that Avalon savvy to implement
something like this currently.

 Yet another alternative is for the extending action to return an
objectmodel
 parameter which is matched later in the sitemap.
 map:action type=myxmlformaction
   ...
   map:call src=cocoon:{whichaction}
This one sounds new, interesting and easy to code. I'll give it a try :-)

Thank you very much.


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-09 Thread Ivelin Ivanov 

- Original Message -
From: Josema Alonso [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 09, 2002 5:35 PM
Subject: Re: how to manage several XMLForms in a sitemap? (it was:
dynamically choosing an action at runtime)


  I am not sure if I would do this like you did.
  There are is a certain lifecycle contract between every Cocoon component
 and
  the container.
  By invoking directly you may be violating this contract.
  I would probably let the sitemap do the forwarding to actions.
  In your case action sets might be good.
  http://xml.apache.org/cocoon/userdocs/concepts/actions.html
 I considered them and maybe I'll use them. I'm trying to make a good
 decision.

  Alternatively you can use one dispatcher action which inherits from
  AbstractXMLFormAction and works directly with the backend based on the
  requested command.
 I see. Someone pointed this one, too, but I'm that Avalon savvy to
implement
 something like this currently.

Just open org.apache.cocoon.samples.xmlform.WizardAction.java

then look more carefully in webapp/samples/xmlform


  Yet another alternative is for the extending action to return an
 objectmodel
  parameter which is matched later in the sitemap.
  map:action type=myxmlformaction
...
map:call src=cocoon:{whichaction}
 This one sounds new, interesting and easy to code. I'll give it a try :-)

 Thank you very much.


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-08 Thread Christian Haul 
On 07.Nov.2002 -- 06:53 PM, Josema Alonso wrote:
[snip]
   //get the Action
   if(actionName.equalsIgnoreCase(EquipmentTypeAction)) {
EquipmentTypeAction equipmentTypeAction = new EquipmentTypeAction();

//add this action to the manager
equipmentTypeAction.compose(this.manager);

This is incorrect. It allows the equipmentTypeAction access the
component manager. Not the other way around.

Please don't invent the wheel a second time. Have a read of the great
introduction to the Apache Avalon Framework.

Basically, your action needs to implement Composable.
Then you need to get a selector for actions (this is not possible with
the compiled sitemap but works with the treeprocessor IIRC)
Then you could obtain a reference to the desired action.
Then you could fire up that action.
Then you would release that action.
And all the time the component manager takes care of invoking the
correct life cycle interfaces of the action if implemented.

If you cannot access the component manager that holds the actions, you
need to setup your own one.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-08 Thread Ivelin Ivanov 

I am not sure if I would do this like you did.
There are is a certain lifecycle contract between every Cocoon component and
the container.
By invoking directly you may be violating this contract.
I would probably let the sitemap do the forwarding to actions.
In your case action sets might be good.
http://xml.apache.org/cocoon/userdocs/concepts/actions.html


Alternatively you can use one dispatcher action which inherits from
AbstractXMLFormAction and works directly with the backend based on the
requested command.
Yet another alternative is for the extending action to return an objectmodel
parameter which is matched later in the sitemap.

map:action type=myxmlformaction
  ...
  map:call src=cocoon:{whichaction}


Ivelin



- Original Message -
From: Josema Alonso [EMAIL PROTECTED]
To: Cocoon-Users [EMAIL PROTECTED]
Sent: Thursday, November 07, 2002 11:53 AM
Subject: Re: how to manage several XMLForms in a sitemap? (it was:
dynamically choosing an action at runtime)


 Well, this is a followup to my previous message regarding this subject.
 I coded the Dispatcher, but I must say I didn't know what I was doing
 exactly. Surprisingly, it works but only from time to time...the behaviour
 is really weird...
 I'm copying the code below and hope someone could review it. I'm afraid
I'm
 breaking something somewhere in my cocoon...

 Thanks.

 ps: remember that I was trying to code a Action that could dispatch other
 actions, so I could call it for as many XMLForms as needed with a
parameter
 and it would choose the right action. Some kind of factory method...

 ---
 package net.josema.xmtrader.forms;

 import java.util.HashMap;
 import java.util.Map;

 import
 net.josema.xmtrader.forms.xmldb.recordings.equipment.EquipmentTypeAction;
 import org.apache.avalon.framework.parameters.Parameters;
 import org.apache.avalon.framework.thread.ThreadSafe;
 import org.apache.cocoon.acting.ConfigurableComposerAction;
 import org.apache.cocoon.environment.Redirector;
 import org.apache.cocoon.environment.SourceResolver;


 /**
  * This action let decide which action to use at runtime based on
  * a sitemap parameter with the name of the action to load.
  *
  */
 public class ActionDispatcher extends ConfigurableComposerAction
implements
 ThreadSafe {

 public Map act(Redirector redirector, SourceResolver resolver, Map
 objectModel,
 String source, Parameters parameters)
   throws Exception {

String actionName = parameters.getParameter(actionName);
Map resultMap = new HashMap();

   //get the Action
   if(actionName.equalsIgnoreCase(EquipmentTypeAction)) {
EquipmentTypeAction equipmentTypeAction = new EquipmentTypeAction();
//add this action to the manager
equipmentTypeAction.compose(this.manager);
resultMap = equipmentTypeAction.act(redirector, resolver, objectModel,
 source, parameters);
   }
   //place for the rest of the if clauses for more actions

   //return the map gotten from the chosen action
   return resultMap;
 }
 }




 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-07 Thread Josema Alonso 
Well, this is a followup to my previous message regarding this subject.
I coded the Dispatcher, but I must say I didn't know what I was doing
exactly. Surprisingly, it works but only from time to time...the behaviour
is really weird...
I'm copying the code below and hope someone could review it. I'm afraid I'm
breaking something somewhere in my cocoon...

Thanks.

ps: remember that I was trying to code a Action that could dispatch other
actions, so I could call it for as many XMLForms as needed with a parameter
and it would choose the right action. Some kind of factory method...

---
package net.josema.xmtrader.forms;

import java.util.HashMap;
import java.util.Map;

import
net.josema.xmtrader.forms.xmldb.recordings.equipment.EquipmentTypeAction;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.acting.ConfigurableComposerAction;
import org.apache.cocoon.environment.Redirector;
import org.apache.cocoon.environment.SourceResolver;


/**
 * This action let decide which action to use at runtime based on
 * a sitemap parameter with the name of the action to load.
 *
 */
public class ActionDispatcher extends ConfigurableComposerAction implements
ThreadSafe {

public Map act(Redirector redirector, SourceResolver resolver, Map
objectModel,
String source, Parameters parameters)
  throws Exception {

   String actionName = parameters.getParameter(actionName);
   Map resultMap = new HashMap();

  //get the Action
  if(actionName.equalsIgnoreCase(EquipmentTypeAction)) {
   EquipmentTypeAction equipmentTypeAction = new EquipmentTypeAction();
   //add this action to the manager
   equipmentTypeAction.compose(this.manager);
   resultMap = equipmentTypeAction.act(redirector, resolver, objectModel,
source, parameters);
  }
  //place for the rest of the if clauses for more actions

  //return the map gotten from the chosen action
  return resultMap;
}
}




-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-05 Thread Josema Alonso 
Well, after reading replies to my emails I have a better idea of wht to do
and unfortunately not a chance to do it.
I explain it.

A quick summary. I would like to manage many XMLForms in my sitemap. I would
like to declare a pipeline like this:
  !-- XMLForms pipeline --
  map:pipeline
   map:match pattern=*
map:act type={1}Action
 !-- XMLForm parameters for the AbstractXMLFormAction --
 map:parameter name=xmlform-validator-schema-ns
value=http://www.ascc.net/xml/schematron/
 map:parameter name=xmlform-validator-schema
value=schematron/equipment-type-sch-report.xml/
 map:parameter name=xmlform-id value=form-insert/
 map:parameter name=xmlform-scope value=session/
 map:parameter name=xmlform-model
value=net.josema.xmtrader.forms.xmldb.recordings.equipment.{1}Bean/
 !-- original XMLForm document --
 map:generate src={page}.xml/
 !-- populating the document with model instance data --
 map:transform type=xmlform label=debug, xml/
 !-- personalizing the look and feel of the form controls  --
 map:transform src=styles/wizard2html.xsl/
 !-- Transforming the XMLForm controls to HTML controls --
 map:transform src=styles/xmlform2html.xsl/
 !-- sending the HTML back to the browser --
 map:serialize type=html/
/map:act
   /map:match
  /map:pipeline

For individual hard coded actions I have it working, but I do not want to
repeat those lines for every form I must configure. The conflicting line is
this one:
map:act type={1}Action

It is not possible to specify the Action at runtime.

I searched through the mail archives and got some replies yesterday and
everything points into the direction mentioned at this message:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=102870549825076w=2

So, an Action Dispatcher (or call it Proxy Action or whatever) is needed so
the action could be choosed at runtime. Unfortunately this involves working
with Avalon components and I have no idea about them. I tried their white
paper at their website but it is too hard for me to understand at this
point...

So, the thing is, has anybody developed a component like this? If so,
please, could you share it?
I believe it's very easy to make one for someone with a good knowledge of
Avalon, hope someone could help me on this. I'm almost there with my
XMLForms-Xindice application and I'd love to share my experiences once
finished.

Thanks you very much to all.


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-05 Thread Markdelanoy 
Well I can explain what I've done which matches your requirements but the 
implementation I suspect is quite different.

First some issues I had.
1.) I like the XFORMS concept but... didn't like the fact that I couldn't represent 
non-forms widgets, e.g. page banners, table of contents, footers, buttons that didn't 
submit data, e.g. were simply URL's etc.  so I created a schema (for my own purposes) 
much like XFORMS but then added a few things like url's, etc.  I removed the concept 
of the model and the bindings and what I'm left with is a schema that describes a UI 
so I called it XUI.  I have separate XUI files for the portlets within my page, e.g. 
banner, toc, footer, 1-n body portlets.  
2.) Cocoon's portal concept.  In my world every page is a portal page (not just the 
home page) in that I break it up into banner, toc, footer, body sections.  since the 
banner, toc, footer rarely change (perhaps due to the user's locale or due to security 
permissions for various features) I can cache this and improve overall page 
performance as only the body portlet(s) is really be generated.  Back to cocoon's 
portal concept.  There's four config/layout files and you need to do it per portal and 
then there's alot of sitemap configuration per portal and this isn't my idea of fun.

So I created yet another schema called XPORTAL (again for my own uses) which declares 
validation file to be used, the portlets, the pagebuilder which should assemble all of 
the portlets into one nice page, etc.

So to wrap this up.  What I've done is create a portalAction that takes an actionID 
request parameter (not a url).  The actionID corresponds to an XPORTAL file.  The 
portalAction reads the XPORTAL file and then populates the sitemap parameters and/or 
the httpRequest object with the necessary parameters to drive the sitemap.

Therefore my sitemap is more like a programming language rather than a set of url 
filters.  XML Metadata files read by actions feed the sitemap with parameters.  So 
there's no hardcoding of a specific URL do this...

The XPORTAL file goes so far as to say should we use SSL for a set of pages, should 
the page(s) be authenticated and if so what handler, what UI look and feel skins to 
use, should we validate the form data (form-validator-action) and if so what 
descriptor file, what set, what actions to redirect to for successful validation 
versus unsuccessful validation, etc.

Each portlet then is described using the WSUI schema from www.wsui.org.  This allows 
me to call out SOAP services or wherever.  I've extended the wsui schema to handle 
cocoon services (XSP).  WSUI files (for me) show what XSP page to use for the 
model/db IO, and what XUI file (implemented in XSL) to use to transform generated 
model XML into a UI form of XML.  The XUI files implemented as XSL (therefore I get 
XPATH and language constructs like for-loops, choose, etc for free) acts like cocoon's 
XMLFORMS action.

I then do a second XSL transform to do the look and feel (skin).  (skin's are know 
within the portal file as the skin should be applied across the entire page.)

Basically I'm creating a web application framework out of cocoon rather than what (I 
believe) most people are using cocoon for e.g. web publishing.

So I'm more than happy to share the XML schemas with the list as well as sample XML 
files to illustrate their usage.  Beyond that... I've followed an iterative approach 
in developing this and the visual aspects were done first, e.g. pagebuilders 
assemblign HTML fragments hardcoded into a sitemap, then pagebuilders assemblign HTML 
fragments retrieved from an XPORTAL file driving the sitemap, then to XSP pages 
instead of the HTML fragments

So if you'd like code too... I'd probably just give you the first iterations (as I've 
saved them off) or so otherwise it would be too confusing if I gave you what I have 
now.  Let's just say it's very different although in the end it takes many familar 
concepts to the cocoon community.

To accomplish what I've done I've really only ever created actions and XSP pages.  I 
heavily use XSL and the sitemap.  I also use the authentication framework and the 
form-validation concepts of XSP.  Beyond that I use all the normal sitemap constructs 
like matchers, selectors, resources, transformers, etc.

If interested I'll send the stuff tonight as the computer I'm on doesn't have access 
to all that stuff.

MD

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

2002-11-05 Thread Josema Alonso 
Hi, Mark.

Thanks for writing. After reading your message I can only say...wow!
I think it is very interesting the way you made things work and I really
would love to see it.

More than that, I'm with you when you say you're doing things from a very
different approach when comparing to the average cocoon users do. So, I
encourage you to document it well, take your time, and make it public on a
website. IMHO, it is something that will help people like me to see Cocoon
with a more open mind.

Anyway, there are too many new concepts for me in your message, I can't try
to understand them all at this stage in my project. So, I should look for
another solution quickly. But I hope I could take a look at your work and
take your approach into consideration for future projects.

Thank you very much.


- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 05, 2002 6:56 PM
Subject: Re: how to manage several XMLForms in a sitemap? (it was:
dynamically choosing an action at runtime)


 Well I can explain what I've done which matches your requirements but the
implementation I suspect is quite different.

 First some issues I had.
 1.) I like the XFORMS concept but... didn't like the fact that I couldn't
represent non-forms widgets, e.g. page banners, table of contents, footers,
buttons that didn't submit data, e.g. were simply URL's etc.  so I created a
schema (for my own purposes) much like XFORMS but then added a few things
like url's, etc.  I removed the concept of the model and the bindings and
what I'm left with is a schema that describes a UI so I called it XUI.  I
have separate XUI files for the portlets within my page, e.g. banner, toc,
footer, 1-n body portlets.
 2.) Cocoon's portal concept.  In my world every page is a portal page (not
just the home page) in that I break it up into banner, toc, footer, body
sections.  since the banner, toc, footer rarely change (perhaps due to the
user's locale or due to security permissions for various features) I can
cache this and improve overall page performance as only the body portlet(s)
is really be generated.  Back to cocoon's portal concept.  There's four
config/layout files and you need to do it per portal and then there's alot
of sitemap configuration per portal and this isn't my idea of fun.

 So I created yet another schema called XPORTAL (again for my own uses)
which declares validation file to be used, the portlets, the pagebuilder
which should assemble all of the portlets into one nice page, etc.

 So to wrap this up.  What I've done is create a portalAction that takes an
actionID request parameter (not a url).  The actionID corresponds to an
XPORTAL file.  The portalAction reads the XPORTAL file and then populates
the sitemap parameters and/or the httpRequest object with the necessary
parameters to drive the sitemap.

 Therefore my sitemap is more like a programming language rather than a set
of url filters.  XML Metadata files read by actions feed the sitemap with
parameters.  So there's no hardcoding of a specific URL do this...

 The XPORTAL file goes so far as to say should we use SSL for a set of
pages, should the page(s) be authenticated and if so what handler, what UI
look and feel skins to use, should we validate the form data
(form-validator-action) and if so what descriptor file, what set, what
actions to redirect to for successful validation versus unsuccessful
validation, etc.

 Each portlet then is described using the WSUI schema from www.wsui.org.
This allows me to call out SOAP services or wherever.  I've extended the
wsui schema to handle cocoon services (XSP).  WSUI files (for me) show
what XSP page to use for the model/db IO, and what XUI file (implemented in
XSL) to use to transform generated model XML into a UI form of XML.  The XUI
files implemented as XSL (therefore I get XPATH and language constructs like
for-loops, choose, etc for free) acts like cocoon's XMLFORMS action.

 I then do a second XSL transform to do the look and feel (skin).  (skin's
are know within the portal file as the skin should be applied across the
entire page.)

 Basically I'm creating a web application framework out of cocoon rather
than what (I believe) most people are using cocoon for e.g. web publishing.

 So I'm more than happy to share the XML schemas with the list as well as
sample XML files to illustrate their usage.  Beyond that... I've followed an
iterative approach in developing this and the visual aspects were done
first, e.g. pagebuilders assemblign HTML fragments hardcoded into a sitemap,
then pagebuilders assemblign HTML fragments retrieved from an XPORTAL file
driving the sitemap, then to XSP pages instead of the HTML fragments

 So if you'd like code too... I'd probably just give you the first
iterations (as I've saved them off) or so otherwise it would be too
confusing if I gave you what I have now.  Let's just say it's very different
although in the end it takes many familar concepts to the cocoon