Re: Suggestion for XHTMLSerializer
Forgive me for jumping in, but people seem to be talking past one another. I don't think you are talking about the same issue(s). Correct me if I'm wrong. Vadim Gritsenko wrote: Joerg Heinicke wrote: On 08.08.2005 21:30, Vadim Gritsenko wrote: Completely wrong. If you find a 1:1 relation between a svg and a bitmap, go ahead man, you're rich. For me a svg serialization is not reversible, you loose layers, labels, structure and of course scalability. Man, 1:1 does not mean that you can go in both directions! You just proved Eric's point. In which way? XSLT serialization (as per spec Eric quoted) provides a way for one way 1:1 transformation of xml into the desired view format exactly in the same way as batik transforms svg into png. XSLT has more capabilities, one even might say that it allows for arbitrary xml transformations - but another will say that's exactly the transformation he needs for his view. From Vadim and Eric: Many (most?) serializers are not reversible and therefore there should be no prohibition on yet another seemingly useful serializer based upon XSLT and its output element. From Joerg: An XSLSerializer (or TRAXSerializer) would require a src attribute and so depend on something outside the sitemap for its behavior. This is a question of side effects. These are two separate and distinct design/implementation issues. Furthermore there were reasons for not using xsl:output information, but putting it into serializer component declaration. Shall they no longer be valid? Design of the Cocoon components does not force you into using xsl:output instruction. Moreover, you are encouraged to split up your transformations into multiple logically separated stages, some of them transforming xml data and some of them applying view, layout, etc details, (and some of them even doing LDAP or SQL DB lookups) and finally, you have an option to serialize this xml into the output format of your choosing. TraxSerializer does not break above design in any single place. It just gives you additional serialization option, which is, coincidentally, explores well documented and understood option of the XSLT specification, which is a plus in my book. That well documented and understood option of the XSLT specification was categorically rejected when designing Cocoon 2.x. It was obviously intended for standalone use just as processing instructions in XML to determine the XSLT or CSS stylesheet. It is fundamentally at odds with the Cocoon pipeline, as has been mentioned on the mailing list for years. TraxSerializer does not force you to put your final view xslt transform into the serializer. And I'd even discourage you to do it - as it, in some scenarios, reduces possibilities of reuse - but in some scenarios it'd be advantageous to add small xslt based serialization instead of writing yet another java serializer. Can you enumerate these scenarios? What could you do for this that you cannot do with a trax transformer followed by one of the existing serializers? What advantage is there over, say, a virtual serializer made up of an xslt transform and a serializer? What is the specific use case? Use cases that currently cannot be handled easily = excellent reason. But some scenarios sounds like (dare I say it?) Flexibility Syndrome. Now, to add some more fodder to this discussion... Are there any other serializers that rely on non-sitemap assets such as template files for operation? Batik uses AWT behind the scenes and the system fonts for example, but does this count? Wouldn't something like a TRAXSerializer add side effects to the concept of sitemap serializers? Currently the sitemap is as much a processing contract as it is a processor. By looking at the sitemap pipeline, you can see what should be read, what the schema/format is at each stage of the pipeline, and exactly what is sent out. The svg2jpeg serializer is not 1:1 as Vadim and Eric have pointed out. They are not equal. However, this does not invalidate Joerg's point. It is a *completely different* point. A better, clearer statement is that serializers are not 1:1 (to be clear, nothing in Cocoon 2 is) but rather 1-1. There have been no end of emails equating reversibility (1:1) to a processing anti-pattern. Currently, what you see in the sitemap serializer declaration is what is output. Introducing a trax serializer means that what you see in the sitemap serializer declaration is only *part* of what is output. There is a huge difference between the two, and I can see why Joerg was so upset. * The svg2jpeg serializer always requires SVG input and always provides JPEG output -- including the mime type of image/jpeg. * The fo2pdf serizalizer always requires XSL:FO input and always provides PDF output -- including the mime type of application/pdf. * A hypothetical trax serializer would require a specific input (elements that the stylesheet is expecting) but the
[RT] MVC Contexts (Was Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?))
This one is long folks. Sorry, can't be helped. Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sure, but the question is: once the syntax starts to get ugly for both because of changes we made to the language that make sense only on transformation and not on generation, would it still be the case? remember that the generation stage has a scripted population stage first, the transformation stage does not! I don't see this distinction: if you look at the global processing chain, there is always a population stage in front of the template engine: 1/ template as a generator ++ +---+ + Flowscript |--(objects)--| Template | ... + data | | generator | ++ +---+ ^ | Template file 2/ template as a transformer +---+ +-+ | Generator |--(xml data)--| Template | ... | | | transformer | +---+ +-+ ^ | Template file Where is the difference? The template lays out some data. In the case of the generator, it's controller-provided data, in the case of the transformer, it's pipeline-produced data. Note that is not limited to a generator, but can also be aggregation, prior transformation, etc, or even some preliminary processing of some controller-provided data. snip/ Is this indeed the case? The flow data is, strictly speaking in this case, the model? The template *may or may not* follow the flow data structure closely. In fact, the flow data is merely a hint or an indicator. The template file has the final say on the data structure. You can send the exact same flow data via sendPage* to two different JXTG template pipelines and get functionally different XML structures (depending on which objects are accessed and how). MVC contexts. That's my new buzzword for the day. When you pull an RSS feed from another site for inclusion in your own site, what is that RSS feed to you? A model right? But to the remote site, the RSS is a view (to a remote database for example), not a model. It's the final form for others to use. But it's still RSS data isn't it? How can it be both a model and a view? Because it's used in a different context. The web browser is the same thing. To Cocoon, HTML is absolutely the view. But to a web browser, it's the model. The HTML renderer+CSS is the view, and the client-side Javascript is clearly the controller. Isn't this all true and MVC is actually dependant upon the scope of the problem at hand. In a high-level view of Cocoon, the model is the object model (Hibernate et al.), the view is the pipeline, and the controller is Flow. But what is a generator in a pipeline? The model? But the model from Cocoon came from Flow? But the pipeline is under no obligation to use that data from Flow. It can use a subset of that data, iterate a data structure multiple times or ignore the data altogether. In addition, it has access to data that Flow didn't give it (Actions). So while it is the view for Cocoon at large, it is in fact it's own MVC context that grabs data as needed just as a client-side Javascript can grab updated information from the server without refreshing the main page (GMail). Who decides if that data is to be used? The pipeline logic as controller. (Ack!) The generator determines which template to use. In the case of JXTG, it loads the template file *and* injects data. The difference between displaying a template file raw or with data is the choice of pipeline components in the sitemap, not Flow. Flow can only produce it's view of the working data set and request a particular pipeline that presumably would put that data structure to good use. The pipeline is the controller here. A browser makes separate requests for the HTML, Javascript files and CSS stylesheets to produce the final view for your pleasure. You don't see the MVC in a browser, you see the result of the MVC, the view. Wasn't this the entire point of the last ten years of the W3C? To specify HTML as a model, Javascript as a controller and CSS as a view? In a different MVC context of course. ;-) So in a pipeline MVC context you have a model, the inital XML (static or a template) that determines the initial structure of the data events (generating SAX events where there previously were none), the controller with modular logic (pipeline-specified transformers and actions), and the serializer as view (what the outside world sees). Cocoon had MVC before the advent of Flow. It simply had a single complete MVC context. Flow gave rise to a new concept I've heard on this list repeatedly, MVC+. But are we really defining M, V, C and some new, unnamed
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
I'm almost afraid to bring this up since I'm coming from a point of view
where I actually like XSLT. Yes, I'm one of *those* people. ;-)
But when I saw this:
Bertrand Delacretaz wrote:
Then, Bob, who's in charge of the final presentation, writes another
template to convert this logical document to, say, lightweight
HTML, for an embedded terminal (no CSS). This gets processed by the
XYZTransformer, which uses the same template and expression engines,
and the same syntax as the XYZGenerator (again, don't worry about
syntax details):
html
headtitle${page/title}/title/head
body
table
tr tl:iter=p in page/person-list
td${p/name}/td
td${p/age}/td
/tr
/table
/body
/html
Aside from missing the tl namespace declaration, I was curious if
people are keeping in mind that the equivalent XSLT stylesheet is:
html xsl:version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
headtitlexsl:value-of select=page/title//title/head
body
table
xsl:for-each select=page/person-list
tr
tdxsl:value-of select=name//td
tdxsl:value-of select=age//td
/tr
/xsl:for-each
/table
/body
/html
This is an XSLT 1.0 literal result element as stylesheet.
(http://www.w3.org/TR/xslt#result-element-stylesheet)
I wanted to point out that XSLT can be used in the same (procedural)
model as is being proposed in the two-step template models. More
elements and fewer dollar signs though. It also leaves the door open
for more complex transformations if needed (using full XSLT) and allows
the documentation load to be distributed by other projects. That and
XSLT transformers have already been performance tuned.
Don't get me wrong, I like the attribute syntax as much as the next guy.
Just saying...
- Miles Elam
Re: [RT] do me a favor, don't call them taglibs
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: snip/ Still, CSS is not enough because is not able to change the layout of things and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). OT For rounded corners at tabs you can use :before and :after pseudo selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after, unfortionally it only works in modern browsers and not in the popular broken one that our custommers tend to have :/ http://dean.edwards.name/IE7/ - Miles Elam
Re: [OT] Roy G. Biv vs Miles Elam
Haha! I had a friend in college (who I had a crush on at the time) who gleefully pointed out that my name backwards was conspicuously similar to male slime. ...she didn't live long. - Miles Elam [EMAIL PROTECTED] wrote: Then again the 'male smile' anagram isn't much better
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call them taglibs)
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
All I ask from a template language:
1) something that HTML designers can edit with Dreamweaver
2) something that doesn't use namespaced tags to identify dynamic
scopes (clashes with #1)
3) something that doesn't use the name taglib
That's pretty much all you have to do to make me happy.
Dreamweaver friendly means basically that it should be attribute
driven I guess?
Any prohibition on (non-HTML) namespaced tags would imply to me that
arbitrary namespaced attributes would be a no-no in Dreamweaver as
well. Stefano, as I haven't ever used Dreamweaver for more than ten
minutes, is this limitation a rendering issue or data entry issue? I
question the position though. Taking two obvious possibilites:
1. Velocity syntax: just plugs in in the best-case scenario as text but
suffers from the danger of having the text #foreach wrapped in a tag
by the editor. Well-formedness is not guaranteed. (I think. Correct
em if I'm wrong.)
2. Namespaced tag or attribute: may not be compatible with Dreamweaver
(strikes me as a serious limitation that needs to be addressed by the
Dreamweaver developers IMHO), but can guarantee well-formedness.
I don't think any solution will be perfect. The best we can hope for is
straightforward workarounds.
I'll give some background info and then I'll show how an attribute
driven template language for Cocoon could look. The discussion is
based on TAL http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL,
Tapestry http://jakarta.apache.org/tapestry/ and some of the
functionallity in JXTG.
Lucky me, I just made my first site with Plone a couple of months ago.
We need two kinds of constructions: expressions and directives.
Expressions
===
Expressions are the ${expr} stuff in e.g. JXTG and should be use
able both in text in attributes and element content. Do we need the
$? Couldn't we just use {expr} as in XSLT?
I'm glad someone else said this. I totally agree. If I understand
correctly, the reason behind the '$' character was to differentiate
JXPath and JEXL expressions. Since the current thought is that we'll
standardize the lookup syntax, why the extra character. It can be said
that people are used to JXTG, but far more people are used to XSLT-style
attribute value substitution.
Also bear in mind that JXTemplateGenerator is already written and code
complete. Any new syntactic sugar would presumably be in a different
sitemap component (even if it were abusively named
org.apache.cocoon.transformation.JXTemplateGeneratorV2). Everyone used
to the old syntax just uses the old JXTG implementation in their sitemap
declarations (I love Cocoon's design for this by the way).
IIUC TAL doen't use embeded expressions but instead replace element
and attribute content with replace directives (in attributes). It
might make it even more Dreamweaver friendly as you can look at
example content instead of expressions in your design window. But it
makes template writing much harder IMO. We could have such replacement
directives if people want it but, I would prefer having embeded
expresions as well.
I as well. In addition, I think that the optimum template language
would be as close to the appearance of the output document as possible.
(Yet another reason I don't personally care for explicit forEach, if and
chose elements; they make it harder to see at a glance how it will look
after processing.)
Directives
==
TAL uses one name spaced attribute for each directive, e.g.:
p tal:condition=here/copyright
tal:content=here/copyright(c) 2000/p
Other than the fact that I would have rathered the attribute were
tal:test instead of tal:condition for brevity's sake, this syntax had
proven to be extremely powerful and easy to understand in my experience.
Tapestry instead uses only one attribute, jwcid, with the directive
name as content.
tr jwcid=loop
tdspan jwcid=insertFirstNameJohn/span/td
tdspan jwcid=insertLastNameDoe/span/td
/tr
I'm a big fan of namespacing the attribute for reasons of versioning as
well as clearly marking which directives belong to which processor --
both for the processor and for the template author.
.
A problem with attribute name as directive is that xml attributes
are unordered. So in the case you need e.g. a double loop over an
element, test if you want to perform a loop or do a loop and test each
element, a mechanism for deciding the order is needed. TAL uses a
predetermined order for the directives. That is far to implicit for my
taste and it doesn't solve the double loop. I would prefer to do
something more explicit like:
p tal:define-1=x /a/long/path/from/the/root
tal:condition-2=x
tal:content-3=x/txt
tal:attributes-4=class x/classEx Text/p
Sounds good on paper, sounds like a royal PITA in practice. Determining
whether attribute A should be set before the first condition but after
the second condition which determines the content...
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Daniel Fagerstrom wrote: And it might make a big difference, from the users point of view, by making it possible to use a single tool for the whole presentation pipeline, and making presentation templates way easier than raw XSLT, which is a major stumbling block for many people. We might want to make it work first, to see how much people like it. If they like it, I'm sure someone will find a way to make it fast, if needed. You're right no need to optimize until we know if it is needed. AFAICS the only reasonable way of accessing the XML input is things like XPath that in general need access to the complete XML-tree. And in that case we can reuse XSLT processor technology if needed. Going for something like STX-style access would be far to complecated for the intended audience. Why is STX considered more complex than XSLT? Sure it doesn't have arbitrary source tree access, but the syntax is very similar to XSLT by design. Instead of xsl:template, you have stx:template. I still think that STX would act as an effective macro expansion mechanism instead of having macros in Java/SAX. - Miles Elam
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Stefano Mazzocchi wrote: What we need is a template language. Period. Something that converts data *structures* into SAX events. Whether you use it for data or presentation or whatever else, it's up to you. Once again, it looks like I should have just read all the comments before replying again. *sigh* For what it's worth, concept resonation has occurred. (aka I agree completely) - Miles Elam
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call them taglibs)
Roy G. Biv wrote: 2. Namespaced tag or attribute: may not be compatible with Dreamweaver (strikes me as a serious limitation that needs to be addressed by the Dreamweaver developers IMHO), but can guarantee well-formedness. Nevermind. Forget I said this. Dreamweaver supports namespaced attributes. - Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Bertrand Delacretaz wrote:
That's what I mean - having a transformer that can use the same
template syntax as used in the generator, so that the template
language can be used for both the generation and transformation steps.
Aren't you really talking about just a transformer then? The current
role of generator would be handled by a FileGenerator loading the
template for processing by the transformer. The processing model would
be kept with the SourceValidity object -- possiblity for reuse whenever
the previous parts of the pipeline are cacheable.
Then the generator simply becomes a virtual one:
map:generator name=template
map:absolutize param=templatename/
map:generate type=file src={templatename}.xml/
map:transform type=template/
/map:generator
A two for one! Only one codebase to maintain. Nothing to keep in sync.
- Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Bertrand Delacretaz wrote: I see the idea, but I think the same thing can be done quite easily in code by reusing the same processing code in the generator and transformer. To what advantage? - Miles Elam
[RT] Formatting and Macros: A tangent on the template/taglib discussion
Here's where I'm at on templates. Feel free to critique.
Goals (in order of importance):
1. Get data from an object model
2. Minimize or eliminate programmatic logic inside the template
3. Make as simple to read/write templates as possible
4. Give feedback on all possible errors
5. Make the data presentable -- follow established Java data formatting
rules where possible
6. Speed
7. Allow extensibility without altering core code
Things to avoid:
1. Making a turing complete programming language out of the template
language
2. Avoid tags that simply duplicate programmatic language structures
(eg. if else forEach)
3. Second-guessing the data model (eg. getInt, getFloat, getString)
4. Programmatic tag libraries for macros (ie. Just use STX, stx:include
and aggregate tranforms)
While I doubt my goals will draw much criticism, the latter group may.
In my opinion, once you fall into if/else/forEach land, you've just
rewritten XSP with attribute markers instead of xsp:logic markers.
I'm probably a broken record here, but there is no difference between
if test=x/ and if(x){}. If the templating process inevitably falls
to them, assumptions about the template tools or that template authors
must write them must be reconsidered. Simplicity and being terse are
key. If an operation can be done with one attribute what would require
three attributes (or one attribute with three directives) for
Turing-completeness, pick the single, simple attribute that is not
Turing-complete.
In addition, I'm wondering what folks think of the following:
-
Template Typing/Formatting
-
Data structures are largely uniform. If I query a bean for a user's
age, it is highly unlikely that sometimes I will receive an integer and
other times receive string or a date during the same data iteration. So
in the efforts toward template simplification, how do we feel about
these two items?
1. No explicit data typing by default (eg.
${user/sallary::#,###.00'/yr'} instead of something like
${formatNumber(user/sallary, '#,###.00\'/yr\'')}) or the current crop of
formatNumber/ and its ilk.
rationale: promotes the use of appropriate data types by the programmer
and relieves the template author of needing to know about typing. The
persistence mechanism most likely has a type specified (especially if a
relational database is in use) and objects in Flow as well. Why force
restatement in the template byt the person arguably least likely to make
an informed decision on the subject? Just pass a format parameter and
be done with it. If the format parameter doesn't fit, report the error
(and location in the template).
2. Use and extension of the java.text.Format hierarchy for data formatting.
rationale: code reuse is maximized and avoids the proliferation of
Cocoon-only APIs.
As was mentioned before, there are only so many formatting variants
needed. I think this covers the bases:
boolean: a selection from two possibilities eg. true/false, yes/no, on/off.
integer (byte, short, int, long): separator placement, percentages,
currency (precision with decimals by division), other bases (hex, octal,
binary)
decimal (float, double): separator placement, percentages, currency,
decimal precision
date/time: basically the SimpleDateFormat syntax featureset
strings (including char and char[]): substring, lowercase/uppercase (Is
this a CSS concern?), xml fragments
unhandled objects: Object.toString() should cover this
Also, integer, decimal, and date/time parameters would have to handle
locale. (Or would a template-wide locale setting in the sitemap be more
appropriate?)
Missing(?) items are formatters for java.math.BigInteger and
java.math.BigDecimal. Also perhaps support for InputStreams/Readers for
larger content (treated as a string or xml InputSource I would assume).
Also a mechanism to add/register new formatters.
By factoring out this code concern and relying upon java.text.Format
implementations, the amount of Cocoon-specific code could be reduced
while referencing standard formatting parameters.
Getting the appropriate format could be accomplished with a
FormatFactory (for lack of a better name) with the following interface:
interface FormatFactory {
public java.text.Format getFormat (String params, Locale
defaultLocale);
public java.text.Format getFormat (String params, Locale
defaultLocale, Object value);
}
The first is called to see if the Format can be determined by the
parameters. The second is called when no formatter was returned from
the first so that the Object's type determines the formatter. As I said
earlier, the types are usually uniform in any given data structure.
Once the type is determined and the format set once, further iterations
could skip this type check and just use the formatter. If there is no
appropriate formatter for the type, a default formatter that simply
calls .toString() would be
Re: [RT] Formatting and Macros: A tangent on the template/taglib discussion
Thank you for the reply. I realize that I'm trying your patience. I
appreciate you bearing with me.
Daniel Fagerstrom wrote:
Roy G. Biv wrote:
Goals (in order of importance):
1. Get data from an object model
2. Minimize or eliminate programmatic logic inside the template
3. Make as simple to read/write templates as possible
4. Give feedback on all possible errors
5. Make the data presentable -- follow established Java data
formatting rules where possible
6. Speed
7. Allow extensibility without altering core code
Seem reasonable. Point 4. seem complicated, care to expand on this.
Concerning point 7., I'm curious, wasn't you in strong oposition
against extensibillity?
Point 4: JXTG does it already. Basically it amounts to saying what went
wrong and what line/column the error in the template occurred on.
Point 7: I was referring to data formatters. Sorry about that.
1. Making a turing complete programming language out of the template
language
Things to avoid:
The important point is not Turing compatibility, BTW I woudn't think
that the attribute language I proposed it Turing compatible.
The important things is IMO, that the language is side effect free and
and has access to the things but not more. What that means is an
important point to discuss. It is also important that the directives
are so well designed so that it is easy to perform common tasks.
Agreed.
2. Avoid tags that simply duplicate programmatic language structures
(eg. if else forEach)
Is this a syntax or semantics question? I.e. does it mean that you
think they are ok as attributes but not as tags or does it mean that
you will rule out such constructs completely?
It means I would try to stop thinking as a programmer and focus on the
problem. I know that seems in contradiction on its face since no matter
what, we're dealing with a computer. But I know for myself, I've spent
so much time with C/C++/Java/Perl/Javascript that if, else, foreach,
while, switch, etc. are all part of my natural language. I like many
many others on this list think in code. The distinction between a class
constant and an instance variable is clear and distinct on an almost
instinctive level due to years of repetition. Singleton and facade
are in our daily vocabulary.
*We as programmers are odd.*
When designing template languages for example, I try to think as someone
who hasn't taken an introductory programming or data structures class in
college. I try to think of my friends who think of if, else, while,
etc. as just a few arbitrary words out of thousands in the English
language. Then add only what logic is necessary to get to a
well-defined target. Since if, else and foreach are all general
programming directives, I consider their presence in a template language
suspect until proven otherwise necessary. Nothing nefarious or
complex. Just a reflex so that I can empathize with the target audience.
4. Programmatic tag libraries for macros (ie. Just use STX,
stx:include and aggregate tranforms)
As said before I don't share your love for STX, I find it rather cool
for applications where I need to do simple things for huge amount of
repetetive data, but otherwise its far to complicated for my taste.
I guess I'm coming from the point of view of the samples for JXTG -- not
the most complex material to work with. Then again, that's the type of
thing that I think of when I hear the term template macro. With the
calendar example, I found the complexity to be the bean and the raw
template directives necessary to iterate that bean. The macro expansion
portion never occured to me to be anything but the most trivial portion
of the equation.
While I doubt my goals will draw much criticism, the latter group
may. In my opinion, once you fall into if/else/forEach land, you've
just rewritten XSP with attribute markers instead of xsp:logic
markers. I'm probably a broken record here, but there is no
difference between if test=x/ and if(x){}.
Yes you are, so I try to avoid repeating my answer ;)
Haha! Sorry about that.
In addition, I'm wondering what folks think of the following:
-
Template Typing/Formatting
-
Yes, what do we think? Take a look at: [RT] Attribute Rendering and
CForms Convertors,
http://marc.theaimsgroup.com/?t=10994198833r=1w=2
all the 78 posts are not about that but many are ;)
A... This makes it clear for me. This also explains why I missed
the discussion. I may just be slow, but I never considered that email
subject line to be about JXTG template replacements. I have been in
general quite pleased with CForm work thus far and saw no need to get
involved with implementation discussions about it. I'm working my way
through the discussion now to catch up.
Miles, it seem that you propose things that are very close to things
that I and others have discussed the design for in previous e-mails.
If there are things that I fail
Re: [Design] JXTG 2.0 (first stab after reading the archives)
Bruno Dumon wrote: On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote: CForms Convertor Integration Here is the Convertor interface: snip/ AFAICS we don't need the formatCache in a convertion component, each convertor will only be needed to be defined once The purpose of the formatCache is if a lot of values need to be converted using the same convertor, which is (or can be) the case in selection lists. Java's DateFormat and NumberFormat classes are not thread-safe, Ok. didn't know that, disturbing :/ so they need to be recreated for each conversion, and this can be quite heavy (eg the number or date formatting pattern must be reparsed each time). The format cache allows to store the prepared Date/NumberFormat instance, but is completely optional. Yes, now it makes perfect sense. Would it be possible to let the convertor manager handle some thread local Date/NumberFormat cache, so that the user of the convertor doesn't have to manage that? Wasn't this precisely why java.text.Format implements Cloneable? eg. formatter.clone().format(...) The idea was that the pattern would not have to be reparsed. In addition, threadsafe formatters could simply return this as the return value to clone(). Would this be less efficient than a format cache? It would definitely be simpler code and a modern generational garbage collector should make short work of the short-lived object. - Miles Elam P.S. Yes, reading the discussion makes me feel more at ease. I still think the email subject could have been clearer though. ;-)
Re: [Design] JXTG 2.0 (Just my opinion)
Stefano Mazzocchi wrote: No, I disagree: there is a place for generation and there is a place for transformation. They are different things and both have a reason to exist. I see where the statement comes from, but doesn't processing begin by loading the template file? Data injection from flow is step 2. Loading the template file seems like the generation step to me, not the data injection. With XSLT/STX, the stylesheet is the manipulative/transformative vector. With a flow template transformer, it's the flow object model. With the i18n transformer, it's the l10n catalog(s). Your dividing line seems somewhat arbitrary. What am I missing? - Miles Elam
Re: [RT] Attribute Driven Templates
Stefano Mazzocchi wrote: For the record: my focus is on having a template language for cocoon that is as powerful as XSP but avoids all the problems. Is that realistic? I can see logicsheets, but XSP was arbitrary Java code. I find it hard to believe that *anything* will be as powerful/flexible as that. Dealing with strict constrains is also a very good exercise of design because it forces you to think rather than just work by symmetry. Indeed. My constraint has been a Simplified DocBook variant which I find to be a much stronger data model than XHTML, but that doesn't make me right. For example: http://geekspeak.org/articles/12/article.xml and the page it produces http://geekspeak.org/articles/12/ Just trying to find the cleanest, most maintainable way there. - Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Ralph Goers wrote: Why would it begin with loading the template? The process begins with the controller accessing the model and then making a determination of what to do next. It might need to go back to the model to obtain another piiece of information to display an alternate screen before displaying the one it collected the inital data for, for example. The template should only be accessed when the data is ready to be manipulated, not before. However useless the action may be, calling sendPage* on a pipeline without JXTG still produces (generates) output doesn't it? I'm not trying to be difficult, even though it may seem so. If you can have a pipeline that ignores the object model passed from Flow, how can that object model be automatically considered an intrinsic part of generation? The Flow object model is available to components further down the pipeline too isn't it? With XSLT/STX, the stylesheet is the manipulative/transformative vector. With a flow template transformer, it's the flow object model. With the i18n transformer, it's the l10n catalog(s). I don't understand this. With these examples the manipulative/ransformative vector is the template, not the object model. That is what is being operated upon. All of the above are transformers and the all operate the same way; they are fed SAX events and output SAX events based upon the XSLT Stylesheet, the template, or the I18n elements. Okay, aside from my obfuscated terminology, how is that true of the I18Transformer? It takes SAX events (just like a template transformer would if the template file were read in from the FileGenerator), but it's catalog data, while stored on the filesystem in XML files, is not read in as a SAX stream; it's an injected data model. The fact that the catalog files are stored as XML is an implentation detail, not part of the SAX processing pipeline. If you were to load a .jx template in the FileGenerator, it's still data. It's still a starting point whether or not there's a Flow bean awaiting iteration. Does JXTG start processing by handling the Flow objects or by reading and parsing the template file. Data injection is secondary. Important, but secondary. - Miles Elam
Re: [RT] Formatting and Macros: A tangent on the template/taglib discussion
Stefano Mazzocchi wrote: 2) at the end, the template is not a file, but the result of a pipeline fragment. In short, the template that DW designers will have to use is a pipeline view, not a file on a disk. How so? The preliminary step(s) before data injection include such items as macros before expansion. In short, the file on disk looks conspicuously like the template generator that does macros internally. I would absolutely expect the DW designer to be referencing the macros pre-expansion, not post-. Whether it's map:generate type=jxtemplate src=template.jx/ or map:generate type=file src=template.jx/ map:transform type=stx src=macros.stx/ map:transform type=template/ This means that in order to allow DW designers to edit their pages, you have to create a special section of the website, hopefully webdav enabled, so that they can open/edit/save those virtual files... also, you need the ability for your first transformation stage to be reversible. It's the origin template (template.jx) that would be edited in DW, not the output of the macro transformer or data injection. If you don't require reversal after data injection to get to HTML for the generator, why would you require it in this transformation model? template.jx is the editable source in either case. I may be working with a Simplified DocBook variant (and have to deal with some WebDAV trickery for editing), but nothing here requires it any more than if I created the file with JXTG to produce said Simplified DocBook variant. XSLT transformation to HTML is the precursor to reversal, not a data injection transformer. - Miles Elam P.S. I use the term data injection, but if that is turning some folks off, is there a preferred term that I should use on this list instead?
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote:
The only difference compared to the SQLTransformer would be that I
can combine it with JXTG constructions and insert query params in a
convinient way.
This is exactly the point that makes me say just say no to taglibs
because, as I explained before, no matter what syntax, putting query
parameters in a SQL string is not something that should be in a template!
Thank you.
Sure, that's a better syntax, but the fundamental problem remains:
template designers don't know nothing about SQL, nor care, nor know
anything about request parameters, not know anything about dynamic
tags nor know how to debug something in case somebody screws up with
the order of those tags!
let me rewrite the above:
controller.script:
var query = SELECT name,description +
FROM projects +
WHERE project= + request.id +
ORDER BY name ;
var results = cocoon.datasources.gump.execute(query);
request.context.set(projects,results);
view.template (content style):
ul
#foreach project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
#end
/ul
or view.template (attribute style):
ul x:foreach=project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
/ul
note how SoC also allows you to use a different technology (example,
O/R or straight OODBMS or even RDF triple stores!) to populate the
beans without the template designers know anything about this!
Thank you! If this isn't a case study of what to do with simple
queries, I don't know what is.
Personally I like:
ul x:test=projects
li x:context=projectsa href=projects?name=${name}${name}/a -
${description}/li
/ul
Where each item in projects becomes the reference scope. ;-) If there
are no projects, no list tags are written. But then, I'm one of those
weird guys who doesn't mind seeing things like ${.} occasionally to
refer to the current iterated item. I also have to admit a love for
test conditionals that don't require the explicit != null grammar.
Hey! We can all dream, right?
One concern though: Is that results variable a result set or just a
collection of data. If the former, how is the database connection
handled (closing or returning to the pool)? If the latter, how can
large result sets be returned without exhausting memory from a few
queries? That's the one case where I see ESQL winning out. All other
cases where you aren't dumping the contents of a table, this seems like
an excellent idea. If a web developer can't handle that much scripting,
what chance do they have with an ESQL taglib?
Sure, I agree with all that. Only question is: where do I put my SQL
queries in the above scenario?
this is the whole stinking point: *never* in the template!
Thank you.
But the whole point of this discussion is: do we need taglibs?
I'm sorry, but I agree with Miles, we don't: all we need is a
velocity/garbage-like template system and recompilable java
controllers.
If you by this mean that you don't see any need in writing special
purpose taglibs as a typical part of normal webapp development, I
couldn't agree more.
No, not only that: I think that the person responsible for doing
writing the logic that drives the flow *and* the content population of
the page is *NOT* the same person that does the design of the template.
Thank you.
- Miles Elam
Re: [OT] EJB 3.0 in JBoss
Peter Hunsberger wrote: We've brought Cocoon up under JBoss 4 and it behaves a litte strangely. Haven't figured out exactly what is going on but it appears that -- with no other configuration changes being made -- Sitemap serializers must now have all elements declared (eg. doctype-public, doctype-private, encoding, etc.). It's as though some DTD or Schema was saying everything is mandatory. I know the Sitemap doesn't declare a DTD or schema directly so I can't understand why this would suddenly show up... That's a shame. I could see a future where one drops an .ejb3 file into the deploy directory and then immediately starts using the object in flow without a restart or extra deployment descriptor/mapping file hassles. I'd be interested to hear if othes also run into this and what the cause might be. As would I. - Miles Elam
