Jeremy Quinn wrote:
>
> At 1:53 pm +0200 11/4/02, Stefano Mazzocchi wrote:
> >Jeremy Quinn wrote:
> >
> >> How can we reconcile the differences between the needs of a generic form
> >> handling mechanism for both Business Logic and Content Management?
> >
> >I say we don't even try.
>
> fair enough
>
> >Forms generate highly structured data while browser-based content
> >editing generates semi-structured data.
>
> This is a key problem, in the case of Business Logic, there is much more
> likely to be a load of text fields that become primitives on a Bean, while
> in a CMS scenario, you would often want to parse incoming form field(s)
> from editing content, because you are not dealing primarily with primitives
> but XML.
Believe me, it gets much worse: we might end up having client-side
technology (see Xopus, for example) that gives you an XML file directly
thru the POST (I've implemented another WYSIWIG browser-based javascript
client that does exactly this and you wouldn't believe how easy it was
to do it.... when Mozilla 1.1 comes out implementing content-editable,
you'll see tons of these browser-based editing environments come up).
> >These datasets are so different they can't be handled (nicely!) with the
> >same database, why would you think this model doesn't apply to the data
> >validation part?
Ok, maybe you haven't being following the debate about native XML
databases, but in short, people think that using relational databases to
store XML content that is semi-structured (for example, an article or a
book) is wrong.
Relational databases are great with tables and poor with trees,
Hierarchical databases are great with trees and poor with tables.
But the world contains data both in tabular form (sometimes called
'structured') and tree form (sometimescalled 'semi-structured').
The act of validating structured and semistructured content is, IMO,
*so* different that requires different mechanisms and different data
storage systems.
This is why I wanted the Xindice project to start: structured data goes
into relational databases and it's validated against structured
constraints, semi-structured data goes into hierarchical databases and
it's validated against semi-structured constraints.
Sure, XML Schema tried to do both at the sime time and this is the
reason why the language is a total mess.
I would not follow the same path if I could choose.
> >Sure, it would be nice to have one-size fits all (as it would be in
> >databases, BTW), but I have the impression that a unified approach is
> >going to be inelegant at least for one of the two sides (if not for
> >both!).
> >
> >What do you think?
>
> Let me keep mucking around in the scratchpad ;)
>
> It would be nice to have a set of reusable components that can be strung
> together as needed to perform any required form-based operation, but then,
> how long can we wait??
>
> Possible generic components ...... ??
>
> A RequestGenerator that uses a descriptor file to build an Instance, which
> could then be Streamed down the pipe, validated and converted to a Bean if
> needed, would be helpful, but this would mean implementing castor-mapping
> in a Transformer.
>
> As I understand it, this is where the current work on the 'Business Logic'
> solution stops being useful for a 'CMS' solution, because everything
> happens 'behind the scenes' of the pipeline in Actions, because they are
> integrating with external 'Business Logic' not WriteableSources.
I haven't yet dived into the details of form validation to be enough
knowledged about the implementation.
The only think I can say now is that we must be careful about
genericizing the validator too much or it could become so abstract and
hard to use that people would be scared away from it.
Moreover, once you have two different systems, one for structured data
and one for semi-structured data (each with different needs), you
wouldn't need anything else so I don't think this apparent duplication
of effort is going to do harm.
But again, I still have to touch implementations.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
