cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: [RT] forms
Date Fri, 20 Jul 2001 13:46:21 GMT
On 19.Jul.2001 -- 07:33 PM, Torsten Curdt wrote:
> 
> What do you mean by "get back"? What I was thinking of was:

I was refering to the form in which the posted form parameters are
represented for further processing. Currently, every form element
corresponds to a request parameter. XForms require each entire form to
correspond to one request parameter. If the suggested names for
elements are used, they're like
"formName/elementName/subElementName". From this one DOM object can be
constructed to hold all parameters of a form, just like XForms
expects. That would enable to delegate validation to xerces but is a
bit more costly.

> > > When a subpage is chosen to be viewed an intance of
> > > an DOMObject referring to the xform id needs to be
> > > looked up. If there is none, one needs to be created
> > > and registered. (Just like the Components in the ComponentManager)
> > > Creation means also passing the SAX events from the
> > > xform:instance data to the DOMObject. Now the DOMObject
> > > holds the expected XForm structure.
> > 
> > I don't quite get what you're at. If this object contains the instance
> > data -- which is likely to be different for every invocation as partly
> > filled in forms return -- why should an instance get looked up?
> 
> I want to save the DOMObject instances inside the session.
> Simplified:
> 
>   xform = (DOMObject)session.get("formid");
>   if(xform == null){
>     xform = new DOMObject();
>     xform.setLexicalHandler(lexicalhandler);
>     xform.setContentHandler(contenthandler);
>   }

OK.

> Some kind of manager would be probably better?!

No idea.

> > If that's the caching concern again, I strongly believe that that is a
> > different concern and should be handled otherwise. E.g. if it's a XSP
> > that generates the form, it's up to cocoon to cache this request and
> > deliver a cached copy.
> 
> Now I'm wondering where you are up to... ;)

Caching should be done locally only if we know a lot better how to do
it than cocoon. Otherwise we should rely on cocoon to do the caching.

> > > * Selection of the subpage based on the validation results
> > 
> > See other reply.
> 
> Could you please outline how you would want to do this?
> I don't really see the problem about this one.

I think we agree that this is independant of forms. I would suggest an
action that knows how many subpages exists (through a session
attribute or a parameter?). So the sitemap would read like

  if validation == OK
       if 0 < requestedPage < lastPage
	    showPage ( requestedPage )
       else
	    showPage ( currentPage )
       fi
  else
     showPage(currentPage)
  fi

Where showPage(subpage) is a call to generate.

BTW something similar could be achieved with the
FilterTransformer. Output all subpages and the FilterTransformer
filters all but the current one from the output.

> > > Then I would propose a XFormTransformer that will
> > > extract the selected subpage fragment and add the
> > > value to the xform elements. Here is an example of
> > > what should come out of the transformer:
> > 
> > What would that be exactly? Fill in the blanks in a form with values
> > from the instance data, like the SQLTransformer?
> 
> yes

I hope a stylesheet would do, but I don't know for sure. Of course if
you intent to do calculations and look up you'd need your own
transformer. But that I fear would be quite application specific. Or
at least I wouldn't see it at the core of a forms package.

Your concern here is how to integrate with forms. Well, you could do
    <form>
       <instance>
           <name><replace-me with="my.bo.method"/></name>
       </instance>
    </form>

And replace with a transformer.


> > With XSP as well.
> > > * taglib would mean to but multiple (sub)pages into
> > >   one XSP page - I'm always afraid of the 64k limitation
> > >   of XSP pages
> > 
> > AFAIK this limitation is a per method limit. So putting each sub page
> > in a different method would circumvent it.
> 
> Hm.. got me. I must admit I feel just more flexible and
> safer not to run into compile time / run time problems.
> Why would you want to go for a logicsheet?

I think it's the most flexible way to do. But I'm not religious on
that.

> > Again this is not compliant. But it is a problem to conform to it
> > here. What about different error conditions? Currently
> > FormValidatorAction offers a number of constraints that each may be
> > invalid. XForms specs only one arbitrary complex constraint returning
> > a boolean. 
> 
> What's the compliant method? I must have missed it in the spec.

That's the problem, there isn't one. XForms does not talk about error
messages :-(

> > > * DBMS comboboxes

> > I still think it's not a form issue. If you're not happy with your
> > DBMS caching the data, well, create an alternative way to contact the
> > DBMS and do the caching in that component like the descriptor caching
> > is done. After all, this might come in handy with other issues as
> > well.
> 
> But still there is the output problem then!

What output problem? Is this again, that I think XSP and you think
transformer? It would be no very nice to have to employ a dozen
specialized transformers... but then cocoon2 is all about putting
pieces together. That's what I like so much about it. Like shell
programming in UNIX ;-)

> > > * output definition
> > >   I think what is not quite clear (at least for me)
> > >   from the XForms spec is what "output" means
> > >   on selections aka choices. Is it the value
> > >   or the text? Both is needed! So how do you specify
> > 
> > I think as with HTML it's the value. If you'd need the text, add that
> > to the value as well.
> 
> Arrrgh... NO! This becoming a real ugly hack then!!
> (not talking about weak browser implementation that
>  might be swamped with long i18n text as values - just
>  a fear)

I see. Shoping cart &c. List of purchased items, not nice to look up
their description more than once. But there's not much we could do
about it. If the HTML reads
      <option value="123456">Some really long description of item</option>
The browser will return "123456" only. What could a forms package do
to this?

> > > * subpage navigation

> > Name the submit button as you like.
> 
> No. There is a difference! Submitting
> a subpage is different from submitting
> the xform!! Submitting the xform means
> "placing the order" while submitting
> a subpage is a navigation inside the
> xform.

Right. But if we think about this in terms of HTML it boils down to
name the submit button a long the lines of "continue..." or "subpage 2
caption". If the device were XForms compliant, we wouldn't have to
deal with sub pages at all. Ah, that's probably a plus for a
FilterTransformer based solution.

> What about putting the whole multipage
> navigation thing into it's own namespace?
> Like:

> So we would have both topics separated.

Agreed.

> But we need a way to report the result
> of the form submission (success/failed)
> to the sitemap. Also a failed submit
> need to show the last page again.

Sure. We'll see.

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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


Mime
View raw message