"Improved" handling of mod-db and actions in sitemap?

[Derek Hohls <DH...@csir.co.za>]

Thanks to Christian and Leo for the suggestions related
to a "comprehensive" database sample.  I think, though, that
I am trying to get things simpler and not more complex.
ie. aim for more and easier reuse of the existing codebase
and approaches, rather than adding in more code and
more approaches...

I was wondering if there was a simple (straightforward?)
way of rewriting the sample pattern for using modular
database actions, in such a way that they can scale more
easily to handle a large (and variable) number of tables.
(ASSUMING that no complex transaction logic is involved)

The sample in $COCOON/samples/databases/mod-db sitemap has:

<!-- add new groups to a user's groups -->
<map:act type="req-params">
  <map:parameter name="parameters" value="add-groups user_groups.uid
user_groups.gid"/>
  <map:act type="mod-db-add">
  <map:parameter name="table-set" value="user_groups"/>
  </map:act>
</map:act>

<!-- add one new group -->
<map:act type="req-params">
  <map:parameter name="parameters" value="add-group groups.gname"/>
  <map:act type="mod-db-add">
    <map:parameter name="table-set" value="groups"/>
  </map:act>
</map:act>

AND

<!-- delete one user -->
<map:act type="req-params">
  <map:parameter name="parameters" value="del-user user.uid"/>
  <map:act type="mod-db-del">
    <map:parameter name="table-set" value="user"/>
  </map:act>
</map:act>

<!-- delete one group -->
<map:act type="req-params">
  <map:parameter name="parameters" value="del-group groups.gid"/>
  <map:act type="mod-db-del">
    <map:parameter name="table-set" value="groups"/>
  </map:act>
</map:act>


This approach means that for each new table or table group you 
need to create a new set of entries in the sitemap.  I was
wondering if it is possible to set up a handling mechanism 
where the number of tables (and their various keys) are NOT
known in advance.   Perhaps something that looks like:


<map:match pattern="add/*">
  <map:act type="mod-db-add">
    <map:parameter name="table-set" value="{1}"/>
  </map:act>
</map:match>

AND

<map:match pattern="delete/*">
  <map:act type="mod-db-delete">
    <map:parameter name="table-set" value="{1}"/>
  </map:act>
</map:match>

where * would be the name of the table-set involved,
BUT - I am not sure how and where to define what request 
parameters need to get handled - if any?  

Any help and/or advice with this would be gratefully
received.

Derek

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


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

Re: "Improved" handling of mod-db and actions in sitemap?

[Christian Haul <ha...@informatik.tu-darmstadt.de>]

Derek Hohls wrote:

> <!-- delete one user -->
> <map:act type="req-params">
>   <map:parameter name="parameters" value="del-user user.uid"/>
>   <map:act type="mod-db-del">
>     <map:parameter name="table-set" value="user"/>
>   </map:act>
> </map:act>

> This approach means that for each new table or table group you 
> need to create a new set of entries in the sitemap.  I was
> wondering if it is possible to set up a handling mechanism 
> where the number of tables (and their various keys) are NOT
> known in advance.   Perhaps something that looks like:
> 
> 
> <map:match pattern="add/*">
>   <map:act type="mod-db-add">
>     <map:parameter name="table-set" value="{1}"/>
>   </map:act>
> </map:match>

> where * would be the name of the table-set involved,
> BUT - I am not sure how and where to define what request 
> parameters need to get handled - if any?  

Derek,
the sample does not do validation. The only thing it does is to check
whether some required parameters are present. To make it very simple and
not distract from demonstrating the database actions, I have chosen to
just check the presence using the above action.

A very similar result could have been achieved by using a constraint-set
with the same name as the table-set and just check for not-null of the
parameters. Please note that the form validation action has very limited
support to refer to another parameter definition.

Please note as well, that it is possible to merge validation descriptor
and datbase descriptor in one file.

To make it even more comfortable, one could think about creating the
validation descriptor automatically by applying an XSLT to the database
descriptor and setting not-null for all keys and checks based on the
datatype for all attributes.

Given that, you could do

  <map:match pattern="add/*">
    <map:act type="formval">
       <map:parameter name="constraint-set" value="{1}"/>
       <map:parameter name="descriptor" 
value="cocoon:/form-descriptor/{1}"/>
       <map:act type="mod-db-add">
         <map:parameter name="table-set" value="{../1}"/>
         <map:parameter name="descriptor" 
value="cocoon:/db-descriptor/{../1}"/>
       </map:act>
    </map:act>
  </map:match>


  <map:match pattern="form-descriptor/*">
    <map:generate src="cocoon:/db-descriptor/{1}"/>
    <map:transform src="database2formval.xsl"/> <!-- to be written -->
    <map:serialize type="xml"/>
  </map:match>


  <map:match pattern="db-descriptor/*">
    <map:generate src="{1}.xml"/>
    <map:serialize type="xml"/>
  </map:match>

In addition, you might want to look into eg Druid IIRC
http://druid.sf.net to generate the database descriptor from JDBC
metadata.

HTH
	Chris.

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