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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
20 matches
Mail list logo
