logo       

Related Msgs: audio.musicbrai...    enbd.general/20...    ietf.idr/2002-0...    java.ant-contri...    gnu.make.genera...    qplus.devel/200...    video.freevo.cv...    os.netbsd.ports...    yellowdog.gener...    xfree86.cvs/200...    search.nutch.us...    freedesktop.xse...    programming.swi...    capabilities.ge...    telephony.pbx.a...    mail.sylpheed.c...    db.firebase.por...    boot-loaders.u-...    recreation.radi...    netbsd.bugs/200...    web.zope.plone....    user-groups.lin...   

Re: Itemset alternative (not working): msg#00025

Subject: Re: Itemset alternative (not working)
hello,

i think we can cut it short by saying: itemset is urgently requested ;)

ok, you're not the first and we heard the call.

all these workarounds are surely not the way to go when itemset would solve that problem. there's good hope for it to appear very soon.

btw, the servlet has been refactored completely and it should be much easier to simply replace it with your own custom version. all real processing is done in ServletAdapter now.


Flavio Costa wrote:

    This is the very same problem we are trying to deal with right now. We
are trying to generate a list from a database table, allowing the user
to choose one row. Then the form may be submitted, taking the user to
another screen with a form with the fields the user is allowed to
change. Here is how we're trying to do it:

<xforms:instance id="C-1" xmlns="" xforms:src="sql://Article"/>

<xforms:repeat nodeset="item" id="repeatArticle">
   <xforms:input ref="title"/>
</xforms:repeat>

    "sql" points to an URIResolver that generates a DOM from the results
of a SQL query. This DOM has the following structure:

<Article>
   <item>
      <articleID>26</articleID>
      <title>some text here</title>
   </item>
   <item>
      <articleID>48</articleID>
      <title>some text here</title>
   </item>
</Article>

    We can choose one of these articles using the radio button generated
by Chiba's XSLT for the repeat. The radio's value is 1, 2, 3...
according to the position. From this we could know which article was
selected when the form is submitted:
dom.getFirstChild().getChildNodes.item(position), where "position" is
Integer.parseInt(request.getParameter("radioname")) - 1.

    The problem is: *where* are we going to do it? For the next page we
have to run a SQL query to SELECT that specific article so it can be
edited. With Chicoon it seems easy, because we could dynamically
generate the next form like this:

<xforms:instance id="C-1" xmlns="" xforms:src="sql://Article/{$myID}"/>

    Now, instead of listing all the articles, we could just select the one
which was picked up by the user. However: we do not want to use Cocoon
since it would be another monster to deal with.

    Do you, Chiba designers, devise another way to accomplish this? If the
hosting XTHML could be pre-processed with XSLT before being sent to
Chiba processor, we could receive form parameters as parameters to the
XSLT and use it to do the job. Anybody else see a simple alternative?

this problem might not be only related to itemset but is a general question of how to chain two forms. something like this should work: use a submit replace="instance". Implement a SubmissionHandler that receives your input (the users choice), execute the SQL statement and return the resulting data as xml. the form session will continue with the data from the response (instance will be replaced). please note, that this implies that you use only one form for the job, but similar could be done for two separate forms. i think from your description that one form should be enough here cause you can show/hide sections of it with relevant or switch but sure this depends on your concrete usecase.



    Of course, it could be said: if you want this flexibily you should go
for Chicoon. But I see this as a fairly common requirement, and
therefore it should be possible to be done using Chiba alone. If we
were planning to use Cocoon, we would be better using Woody or another
form processor already provided for Cocoon itself.
sure, if you don't want cocoon for other reasons its nonsense to use it as Chiba execution platform.



    Sorry for the lengthy and complex message, but we hope to find a
solution so we can be effectively adopting Chiba.

you're welcome


Joern

    Best regards,

    Flavio Costa





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Chiba-developer mailing list
Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click



Try Searching:
servers, voip, java, networking, microsoft ...
<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

Home | blog view | USPTO Patent Archive (NEW!) | advertise | OSDir is an inevitable website. super tiny logo