El mié, 22-03-2006 a las 11:06 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 21-03-2006 a las 10:53 +0100, Thorsten Scherler escribió:
>
> ...
>
> > IMO this internal structurer definition do not belong into the {xdocs}
> > dir.
> >
> > Resource types specific structurer have to be stored in a different
> > folder then the xdocs dir as well.
> >
> > IMO it makes sense to move them out of the xdocs dir and have something
> > like
> > structurer/
> > |-- internal
> > |-- resource-types
> > `-- url
>
> Can the location be defined in either a property or the locationmap? The
> user should be able to specify these locations.
>
Well, yes, since this location are *additions* to the current locations
of the lm the user can override it on a project base. I do not find time
to implement the forrest.properties.xml in the dispatcher ATM (and not
in near future), so if somebody want to have this she needs to send a
patch.
> Your suggestion is fine for the defaults though.
>
> However, please, make this backward compatible. There are a number of
> sites using Views and it is becoming really difficult to keep track.
> Yes, I know it is in whiteboard, and that is the risk on takes, but
> deprecating rather than removing would be more appropriate in this stage
> of the dispatchers development I would think.
Like said this new locations will be added to the lm and they do not
replace current ones. Sadly a @deprecate does only work on java files
AFAIK, but we should update the docs that say to place it into the xdocs
dir.
Regarding backward compatible in general for views/dispatcher/... we
said that we do not care about it.
More, I have reached the point in development (right now) where I see
the dispatcher way too forrest specific and I want to remove all what is
"forrest only". There should be no code in the dispatcher that forces
the user to actually use forrest (forrest is one out of many excellent
frameworks), the dispatcher is an independent component/framework (well
heavily incooperating the lm) and should be seen as it.
That leads to the need to extract as well the lm from forrest core and
to make it to a component on its own (maybe to store the lm in a plugin
makes the most sense).
Actually I am thinking it would make sense to make the dispatcher a
project on its own and support different frameworks, like e.g. Struts.
Maybe starting as the first forrest subproject which offers different
contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
plugins, modules, .... Further I am dreaming of a no-cocoon based
implementation of the dispatcher, like as an extension for mozilla
(written in POJ - I more and more understand Stefanos opinion "that
cocoon has become obsolete").
That has as well the big advantage that forrest user do not have to use
the dispatcher but can rather keep on using skins, which will stay the
default rendering mechanism for forrest.
>
> > To solve FOR-621 with http://forrest.apache.org/docs_0_80/cap.html is
> > not enough.
> >
> > "SourceTypeAction assigns a "type" (a string) to an XML file. This is
> > done based on information occuring in the header of the XML file, up to
> > the document (root) element."
> >
> > This solution works perfectly for xml files but there are so many
> > non-xml files and formats that can mean a different source type and
> > needs a different structurer.
> >
> > We need a counterpart of the SourceTypeAction for non-xml formats and
> > keeping such information in meta data seems the most logical way.
> >
> > wdyt?
>
> How are we to process non-XML formats in an XML publishing environment?
> Can you give an example of the kind of file you are thinking of
> processing in this way.
All binary files. In lenya we are discussing this ATM regarding
resources. A image is content as xml, as plain text, as ... Now imagine
a movie as content, this movie can have meta data and we could render
this meta data in combination with the movie to a view-movie page
(containing the mov and the meta data information). Or to a edit-movie
page (if we find e.g. a movie editor that works in a browser).
>
> I ask because at present all non-xml files are simply read and served.
Yeah, we are doing the same error here as in lenya and ignoring this
files. Further we are "hidding" the processing within high complex code
like our core resource.xmap (lots of magic and no comments).
> It sounds to me like you have a way of improving on this, but I don't
> understand how.
>
> Ross
Well think of the libary on your computer that is connecting file
extensions with applications. e.g. as soon as I click on a png, gimp is
opening up. This is the same idea but in a *web based* environment. Who
said one cannot edit an image with the browser? ;)
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
