Well, that does it. Dispatcher
sounds great, Looking forward to becoming familiar with it for solving
I appreciate your answers - really needed to see if I was off on some
extreme tangent for no reason, or
just off on a tangent...with some app design decisions to make.
Thanks for clearing that up so patiently.
Thorsten Scherler wrote:
El dom, 22-01-2006 a las 17:27 -0500, Helena Edelson escribió:
I won't get into the Dispatcher here, so I'm sending it to user@FAO.
;-) I thought so.
Do you mean implement a c_include on the
xdocs (before skining)?
Yes, I thought about that, but since you need to add stuff that is not
valid xdocs 2.0, what I understood from what you describe further down,
you can not use it.
Would need to set up some control since the content I'm trying to get
into a document is different or not needed for each.
Yeah, you end up adding transformers with custom xsl that control when
to cinclude stuff and override core pipes in your project. Real messy to
maintain and not trivial to do.
I've been testing some of my own hacks (manglings) for getting meta data
into sections of xdoc xml content files(document 2.0 dtd)
So actually it would not be possible to transform this into xdocs prior
the inclusion right? Then you need to implement it in the
document-to-html.xsl but like said above and already noticed by yourself
it will become the maintenance hell.
This is simple with xslt files, jsp/servlets, php where aspects are
easily split so one can set in say a language file
the messages to output (Forrest has this but..) in various areas of the
That sounds like you want to include another language in the content,
Well, not in this instance. I was thinking about a php app, or some
java things where there is a string config file for instance,
allowing you to get fields into the content area (xdocs), but there is
code controling what goes where when, which xdocs content won't.
Yeah, that exact problem is addressed by the dispatcher but I cannot
think about an easy way to imitate this behavior. Further the dispatcher
focus not so much on xdocs but rather react on requests. Meaning you can
generate a html file for a request where no xdocs can be found.
The only way I see is to customize both common document2html.xsl and
(very messy:reusability rather sad)
Yes, that is why I started the work on the dispatcher aka views. Here
you can easily define custom business services that you can include and
process in your output.
I get error:ext:lenya-zone for the resulting URL.
jeje, sorry, like I stated it is the lenya docu so if you want to use
the exact markup you would need to add (to your site.xml):
ah, that is what I thought but didn't do.
That it first needed to be plugged in there, thanks.
Otherwise just try:
Is it worth waiting on this and helping to test the Dispatcher?
IMO that is the best you could do. You have reached a point that I had
when I decided that we need something more powerful then skins.
I've been trying everything off an on for a while now.
no luck yet.
Yeah, because it is not trivial at all.
Yes, it's rather massive. I could never figure out how to solve the
maintainability or reusability issue without a mass of very strange
Not the road to go down.
Which after trying many tests over a few months, finally
drove me to check here - this user list is like pulling out your gps
to figure out
if you're in the right spot or horribly lost!
...but the good news is that I want to release the dispatcher before
14.02.2006 out of the whiteboard.
sorry for not being a bigger help, but skins are way too inflexible to
give you useful code tips about your problem.