On Thu, 07 Jun 2001 13:18:11 -0500 Ian Bicking <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
[XMLC]
>>
>> It's this part which supposedly makes it so compatible with WYSIWYG HTML
>> editors.
>
>While it makes it really compatible, I have to say I am rather
>unimpressed with it. It's not concrete -- you can't see the id tags
>in a WYSIWYG editor. And it doesn't deal with the common situation of
>inserting values -- i.e., that you sometimes define blocks, you
>sometimes define repeating blocks, but probably the most common thing
>will be to define insertion points. An id tag seems a crude way to do
>it.
Yes, obviously one is going to come up against the lack of visual support for
id tags in numerous editors, but that may be because most editors are really
designed for static page design and id tags are probably rarely of interest in
that discipline.
>Like I pointed out in a reply to Mike, entities aren't powerful enough
>to replace the other statements. And the other statements aren't
>individually powerful enough to replace statement nesting.
One would only require entities within tags, but then my systems don't do
insertion inside tags. Where there is an XMLForms element, a new element with
appropriately configured attributes is substituted upon instantiation.
>I only tried to use it once -- to turn a database query result into a
>formatted page. You definitely have to think in the abstract, since
>the XSL layout isn't related to the layout of the resulting page.
To an extent, this is a good thing, since you can then target different media
without worrying about the details of them all. However, people will always
want to tweak the output...
>Eventually it just pissed me off, because I couldn't for the life of
>me figure out a way to do sorting and grouping at the same time. And
>I think I'm better than the average bear at fitting my goals with odd
>execution models -- but maybe I'd retry XSL if another good situation
>arose.
The XMLForms package doesn't rule out other template systems, even when using
it as a template instantiator. However, things could become quite complicated
with a pipeline of transformations going on.
[Decent XML editors]
>Well, if XML tools aren't quite up to snuff, XML/XHTML combo tools
>aren't even on the horizon -- they are something I think people have
>considered for a long time, before even XML existed, but never really
>done. I suppose, though, that there is a certain support to it --
>lots of tools allow you to insert custom tags, which would probably
>suffice (at least if the xhtml namespace was the default, and the
>XMLForms namespace was qualified -- but I guess that's an XML syntax
>issue, isn't it?).
Naive tools could potentially deal with the XMLForms template tags (and even
the model tags) as custom tags, even without namespace support. That might be
an interesting thing to investigate.
>How would you do my example with the conditional highlighting? Like,
>in DTML:
>
> <tr bgcolor="<dtml-if c>#ffdddd<dtml-else>#ffffff</dtml-if>">
> [lots of complicated structure that shouldn't be written twice]
> </tr>
I wouldn't. ;-) Seriously, I might consider making a special formatter for
groups or simple XMLForms elements which generates the necessary XHTML. There
are probably a few extra things required to handle alternatively coloured
collection elements, and tricks like that. However, XMLForms really
concentrates on unifying input and output data models - more presentation-
oriented issues could be handled with another transformation stage.
>This seems to be the example that no system does very well, though ZPT
>comes close if you do the conditional earlier, and then set the
>attribute based on a saved value from that.
It's the only case from DTML which I used before and which I haven't addressed
properly in XMLForms.
>Kind of on a different topic: my own sense on form generation is that
>the HTML generation should be done by a template system in the
>abstract -- i.e., you should just make your
>definition/validation/conversion part of the forms seperate, and they
>provide the HTML elements (INPUT, FORM, etc) in some fashion that is
>easy to plug into a template system -- like as a dictionary
>({"username": '<input type="text" name="username" size="10">'}), or as
>a function with methods (like an input(elementname) function, form()
>function, etc).
>
>Then a user can adopt the form interface seperately from the template
>interface. You can make a template system, they should just be
>friendly with each other, not too closely tied.
>
>Maybe your code is already arranged like this -- but if so, then I
>think you should be more explicit, like give them two different names.
I must upload the newer documentation which describes the structure of the
framework. Effectively, though, the formatting "behavioural traits", which are
mixed into the XMLForm definition's document element object, provide the means
of inserting the appropriate XHTML elements into the final output.
These "traits" are closely related to the API used to generate that output;
currently, the DOM API is used to generate the final output, so the formatting
also uses DOM to put the substituted elements into that output.
It might be possible to use a different API to record the substitutions and
then pass the details on to another template system. That's certainly something
which I could look into.
Regards,
Paul
--
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-discuss
