First of all .. thanks for the help !
I've been a complete cocoon fan for 3 weeks now .. I've converted most of my
team to it ! :)
> There has been a problem using nested actions in an action-set in 2.1
> and most likely treeprocessor in 2.0.x.
.. Ok .. i�ve been using 2.0.3 .. it seems the "stable one" ! :) ..
Btw is there some list of 2.0.3 bugs or problems ?
> > Must i declare a table-set for each operation combination ? (like DOM as
> > foreign key but DESC has not, and so on ..)
>
> This or a cocoon-action-* parameter for every combination. Personally,
> I'd prefer not to use an action-set but code the selection logic myself.
.. you mean declaring it on the pipeline and not on a action-set ?
>You sure want to do form-validation (XMLForms or other), don't
> you. That or the RequestParameterExistsAction would come in handy
> here. I see that you already use the latter.
Yes .. that was the plan ! :)
> > If i use a mode like "attrib", i'm using it for all the foreign keys ..
i
>
> You don't have to. You can change the mode-name for every attribute
> and every mode-type. The mode-type can be specified through the
> table-set. In addition there's the "all" mode-type that would be used
> regardless of the requested mode-type (if the requested type wasn't
> found before).
Ok, i got this, but my problem comes from the fact i've got 3 foreign keys
that sometimes get their value from a request parameter and sometimes from a
request attribute (from the add action on table which is referenced) ..
Can i specify something like this ? .. the mode name and mode type of the
request attribute is diferent on each foreign key ..
<table name="SIGLAS">
<keys>
...
</key>
</keys>
<values>
<value name="NOME" type="string"/>
<value name="DOM_REF" type="int">
<mode name="attribute-dom"
parameter="org.apache.cocoon.components.modules.output.OutputModule:SIGLAS_D
OMINIOS.ID[0]" type="attrib-dom"/>
<mode name="request" parameter="SIGLAS_DOMINIOS.ID" type="all"/>
</value>
<value name="DESC_REF" type="int">
<mode name="attribute-desc"
parameter="org.apache.cocoon.components.modules.output.OutputModule:SIGLAS_D
ESCRICOES.ID[0]" type="attrib-desc"/>
<mode name="request" parameter="SIGLAS_DESCRICOES.ID" type="all"/>
</value>
<value name="QUEM_REF" type="int">
<mode name="attribute-quem"
parameter="org.apache.cocoon.components.modules.output.OutputModule:SIGLAS_Q
UEM.ID[0]" type="attrib-quem"/>
<mode name="request" parameter="SIGLAS_QUEM.ID" type="all"/>
</value>
</values>
</table>
So .. how do i use this ? In a table-set like this ?
<table-set name="all-siglas">
<table name="SIGLAS" others-mode="MODE NAME HERE ?" >
</table>
</table>
But in this solution i can only use the mode i specify on others-mode ! .. I
need diferent values .. one for each foreign key!
Can something like this work ?
<table-set name="all-siglas">
<table name="SIGLAS">
<mode name="something" type="something"/>
...
</table>
</table>
> > want to get the ID by a request attribute only on from the tables i
inserted
> > before. The ones i selected (not added) are just on the request
parameter !
>
> CVS 2.1 has a ChainMetaModule that allows to specify a preference list
> of InputModules. The first one returning a value != null is used. I'm
> currently working on something in that area. Once that is finished,
> 2.0.4-CVS will get updated. In the mean time, it should be safe to
> copy it together with the AbstractMetaModule from 2.1 to 2.0.4,
> rebuild, and add it to cocoon.xconf if you need it fast.
YES! .. my main problem is the != null ... specifying a foreign key from a
request attribute returns null if the attribute doesn�t exists.
I will check this "ChainMetaModule" ..
Btw can you recommed a cocoon CVS version stable to run on a production
server ?
> > Is there any "ConvertAllRequestParametersToRequestAttributes" action ?
>
> I believe so. If not, it's no big deal writing it yourself. The
> ChainMetaModule from 2.1 is another solution.
Ok .. if everything else fails, i will convert all the request parameter to
attributes !
> > I've come to the conclusion it is faster to write some logic on a couple
of
> > XSP's than to use the actions this way.
>
> If you don't mind to mix concerns, that is. The problem with your
> scenario is that you want everything to happen in one invocation of
> the actions.
Yes .. in fact i'm using an real application as an example .. I have some
FORMS that need to perform a lot of operations on diferent tables. It's not
well-formed from a design point of view but it helps the user-interaction.
Thanks again for the help ..
[--] Rui Pedro Leal
[--] [EMAIL PROTECTED]
[--] [EMAIL PROTECTED]
[--] ICQ: 318173
---------------------------------------------------------------------
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]>
