You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2005/10/31 11:04:14 UTC
vague issues with Forrest use
(Sorry, this got too long but i reckon it is important.)
As you know, various people are using Forrest.
For some see: http://forrest.apache.org/live-sites.html
We can only presume they are well aware of what they are doing.
They have chosen to use the pre-1.0 software. They will all
have someone who knows how to run forrest, and knows to ask
questions on the forrest user mailing list if they get stuck
with upgrading, usage, installation, etc.
However, i wonder if we are doing such a good job with
making software that is usable now, even though it is a
long way off being a 1.0 release, that some people/projects
are getting themselves into hot water by depending on it
before it is actually ready.
We need to emphasise in our documentation, and in the
release announcements, that this is pre-1.0 software.
Yet still we can show that it is certainly usable for
those who are prepared to move with it. We use it.
I am particularly concerned about certain meta-projects at
the Apache Software Foundation. For example, xml.apache.org
and incubator.apache.org
These places decided to use Forrest long ago, IIRC at 0.5
However, they do not now have people who understand how to
use it, how to upgrade it, how to get around its quirks.
Especially at Apache Incubator. The people are there
to introduce new projects, new people, and to write and
publish documentation.
I don't quite know the history of Incubator, but i presume
that people got excited about eating Apache dogfood and
decided to go with Forrest. Perhaps the original proponents
moved on. Now it seems that people are not happy with it,
finding it cumbersome. I have heard some people say
that they can't actually point to any particular thing.
Mostly it is just silence and lack of use.
Recently it was proposed that Forrest might be a solution
at another part of ASF Infrastructure. That met with a lot
of criticism, yet there was not a lot of concrete feedback.
Over-dedicated volunteers like me and Ross, tend to go and
help such places. However that is not sustainable.
I don't know what to do about this. At the least
i thought to send this mail because the Forrest PMC
should be aware that there is something happening that
could be damaging for our project. People are gumbling.
We need to look at ways of making it more user-friendly.
It is obviously not easy or the incubator.apache.org
issues would not arise.
Perhaps the problem is documentation for how to install
and use forrest. These projects have a smattering
of their own documentation for how to use it, but often
it is poor and way out-of-date. Perhaps we need to
write a document focussed on use of Forrest at Apache.
Perhaps we need to actively go out and ask those
Apache projects that use Forrest, what they see as
the hindrance. It seems to me that people must be
grumbling but not actually saying that they have issues
or perhaps not being able to define the issues.
-David
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Paul Bolger wrote:
>
>>>>>- A simple, intuitive way for non-XMLers to add things to site.xml
>>>>
>>>>Have you any suggestions about what this may look like?
>>
>>Not sure how technically possible this is, but how about a directory
>>parser which builds the site nav? In other words the user would create
>>a directory structure, arrange their source files where they want them
>>to appear in the site map, and the parser would build the site
>>structure in site.xml as a mirror of that directory structure.
>>I realise that this would sacrifice flexibility, but I think a lot of
>>users would use a 'quick and dirty' site design method (particularly
>>one where rejigging the site structure would be as simple as moving
>>the source files).
I've implemented this in a few different ways but never been totally
happy with the results. The problem is in a dynamic environment where
caching seems to get in the way, for a static site they qork well.
Because I'm not happy with them they remain undocumented. If someone
were to play with them an improve them it would be great.
One of my experiments was reasonable succesfull and is in SVN:
Directory Reader
================
This is almost exactly what you describe. You can see it in the Resume
plugin in whiteboard. In particular:
<map:match pattern="team/all.source.xml">
<map:generate type="directory"
src="{project:content.xdocs}/team/resume">
<map:parameter name="include" value=".*.xml$"/>
</map:generate>
<map:transform src="resources/stylesheets/directory2resumes.xsl"/>
<map:transform type="cinclude"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="resume.site.snippet.xml">
<map:generate src="cocoon:/team/all.source.xml"/>
<map:transform
src="resources/stylesheets/resumes2resumeSiteSnippet.xsl"/>
<map:serialize type="xml"/>
</map:match>
Now just add a cinclude to site.xml for the "resume.site.snippet.xml"
and you get an index of all resumes in the /team/resume directory.
The main problem with this is that the resumes have to go in a specified
directory - not flexible, as you observe, but very easy to use.
Since writing that plugin we have made the locationmap actually work, we
now have a level of flexibility over the location of the files we want
to generate an index for without having to touch the plugin sitemap. So
this approach can be improved considerably now.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Paul Bolger wrote:
>
>>>>>- A simple, intuitive way for non-XMLers to add things to site.xml
>>>>
>>>>Have you any suggestions about what this may look like?
>>
>>Not sure how technically possible this is, but how about a directory
>>parser which builds the site nav? In other words the user would create
>>a directory structure, arrange their source files where they want them
>>to appear in the site map, and the parser would build the site
>>structure in site.xml as a mirror of that directory structure.
>>I realise that this would sacrifice flexibility, but I think a lot of
>>users would use a 'quick and dirty' site design method (particularly
>>one where rejigging the site structure would be as simple as moving
>>the source files).
>
>
> I have never used it, but i think that that is already
> possible. Look in a forrest.properties from a seed site:
> #project.menu-scheme=tab_attributes
> #project.menu-scheme=directories
>
> The former is the default.
>
> http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
> Directory-based selection
I don't think this does what Paul is suggesting, I think this is about
which parts of the menu are shown when a particular tab is slected. I
could be wrong though ;-)
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> David Crossley wrote:
>
>
>>I have never used it, but i think that that is already
>>possible. Look in a forrest.properties from a seed site:
>>#project.menu-scheme=tab_attributes
>>#project.menu-scheme=directories
>
>
>>The former is the default.
>
>
>>http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
>>Directory-based selection
>
>
>>However site.xml has two functions: menus and linking.
>
>
> As far as I was able to find out, that option will only influence what
> tab is _selected_ depending of the directory that the current page is
> in. It does _not_ make Forrest generate a directory-tree-based navigation
> structure.
>
> Yet I remember that Ross was pretty close to finishing a plug-in
> for doing that last summer. Ross???
>
Just in case you missed my overlapping reply (in this thread), it's in
the resume plugin in whiteboard. My reply here describes how it works.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ferdinand Soethe <fe...@apache.org>.
David Crossley wrote:
> I have never used it, but i think that that is already
> possible. Look in a forrest.properties from a seed site:
> #project.menu-scheme=tab_attributes
> #project.menu-scheme=directories
> The former is the default.
> http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
> Directory-based selection
> However site.xml has two functions: menus and linking.
As far as I was able to find out, that option will only influence what
tab is _selected_ depending of the directory that the current page is
in. It does _not_ make Forrest generate a directory-tree-based navigation
structure.
Yet I remember that Ross was pretty close to finishing a plug-in
for doing that last summer. Ross???
--
Ferdinand Soethe
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
>
>>As for mangling the names to get the right order - it makes me shudder!!
>>But if users would prefer it then it could be made an option.
>
>
> Keeping it simple is sometimes more important than fancy architecture.
>
> And it doesn't hurt to provide such a simple plugin as an alternative
> approach to get started.
>
Wow, can you beleive it, McPlugin forgot how easy it is to create
plugins. I even suggested, some time ago, that we could have seeds for
different types of users that would adopt the relevant plugins. So we
could have a "quick start" seed that used this site.xml generator.
Anywone care to create this internal plugin? It's only really a matter
of adapting what I have already done in the resume plugin.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> As for mangling the names to get the right order - it makes me shudder!!
> But if users would prefer it then it could be made an option.
Keeping it simple is sometimes more important than fancy architecture.
And it doesn't hurt to provide such a simple plugin as an alternative
approach to get started.
--
Ferdinand Soethe
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
not sure what happened there - Gmail hiccup! My apologies.
On 11/3/05, Paul Bolger <pb...@gmail.com> wrote:
> > As for mangling the names to get the right order - it makes me shudder!!
>
> Although I've found for big sites it's not a bad idea to use the ISO
> date-of-creation/page-subject-event as the first part of your file
...........
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
> As for mangling the names to get the right order - it makes me shudder!!
Although I've found for big sites it's not a bad idea to use the ISO
date-of-creation/page-subject-event as the first part of your file
name anyway, particularly for content such as news stories, press
releases, articles.
If your page titles and headings are being used properly the filenames
should be of minor importance to the audience.
>
> > I tend to use SSI's for nav. I also use CSS to filter the output of
> > those includes. For instance the developer manuals would be
> > class="dev" and in the user site .dev would have a display:none value.
> > That's if I needed the the two lists completely merged into user, dev,
> > user, dev etc.
>
> The problem with the 'CSS to exclude stuff' approach is that you are
> using bandwidth to send informaition that is not being displayed. This
> may not be significant in low traffic sites (like my own). But for
> something like the Apache sites it mounts up very quickly, that is 1
> million lots of 100 extra bytes adds up to lots of bandwidth.
>
> The reduction of bandwitdh use is one of the goals of the project.
I agree, to a point. If you take a look at the actual code weight of
doing a trick like that - assuming that it's laid out properly, as an
unordered list - it doesn't come close to the sort of bloat which a
WYSIWYG web authoring program can generate. Dreamweaver can turn four
rollover buttons into three screens of code.
...but this segues nicely into another Forrest issue I think we should
be looking at: cleaning up the html output, and probably attempting to
make it xhtml.
I think another thread is called for.
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>As for mangling the names to get the right order - it makes me shudder!!
>
>
> Although I've found for big sites it's not a bad idea to use the ISO
> date-of-creation/page-subject-event as the first part of your file
> name anyway, particularly for content such as news stories, press
> releases, articles.
> If your page titles and headings are being used properly the filenames
> should be of minor importance to the audience.
I agree, antoher concern is that not everyone speaks English, I'm amazed
at the internationalised sites that stick with English page names in
URLs - what is the point?
>
>>>I tend to use SSI's for nav. I also use CSS to filter the output of
>>>those includes. For instance the developer manuals would be
>>>class="dev" and in the user site .dev would have a display:none value.
>>>That's if I needed the the two lists completely merged into user, dev,
>>>user, dev etc.
>>
>>The problem with the 'CSS to exclude stuff' approach is that you are
>>using bandwidth to send informaition that is not being displayed. This
>>may not be significant in low traffic sites (like my own). But for
>>something like the Apache sites it mounts up very quickly, that is 1
>>million lots of 100 extra bytes adds up to lots of bandwidth.
>>
>>The reduction of bandwitdh use is one of the goals of the project.
>
>
> I agree, to a point. If you take a look at the actual code weight of
> doing a trick like that - assuming that it's laid out properly, as an
> unordered list - it doesn't come close to the sort of bloat which a
> WYSIWYG web authoring program can generate. Dreamweaver can turn four
> rollover buttons into three screens of code.
Yes, but that's comparing apples to oranges. Forrest is not a WYSIWYG
bloat system and if you feed content into it that is generated with such
a system it strips much of the bloat. Every byte counts.
> ...but this segues nicely into another Forrest issue I think we should
> be looking at: cleaning up the html output, and probably attempting to
> make it xhtml.
> I think another thread is called for.
+1
Prior to the other thread starting I'll say:
I was hoping this would be part of the XHTML2 move, but that seems to
have completely stalled as it is constantly waiting for some other thing
to happen first. This is another good reason to just get on with it.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
> As for mangling the names to get the right order - it makes me shudder!!
Although I've found for big sites it's not a bad idea to use the ISO
date-of-creation/page-subject-event as the first part of your file
name anyway, particularly for content such as news stories, press
releases, articles.
If your page titles and headings are being used properly the filenames
should be of minor importance to the audience.
>
> > I tend to use SSI's for nav. I also use CSS to filter the output of
> > those includes. For instance the developer manuals would be
> > class="dev" and in the user site .dev would have a display:none value.
> > That's if I needed the the two lists completely merged into user, dev,
> > user, dev etc.
>
> The problem with the 'CSS to exclude stuff' approach is that you are
> using bandwidth to send informaition that is not being displayed. This
> may not be significant in low traffic sites (like my own). But for
> something like the Apache sites it mounts up very quickly, that is 1
> million lots of 100 extra bytes adds up to lots of bandwidth.
>
> The reduction of bandwitdh use is one of the goals of the project.
I agree, to a point. If you take a look at the actual code weight of
doing a trick like that - assuming that it's laid out properly, as an
unordered list - it doesn't come close to the sort of bloat which a
WYSIWYG web authoring program can generate. Dreamweaver can turn four
rollover buttons into three screens of code.
...but this segues nicely into another Forrest issue I think we should
be looking at: cleaning up the html output, and probably attempting to
make it xhtml.
I think another thread is called for.
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>Because this is no longer Vague - you have made a very concrete
>>suggestion. The change of subject makes it much easier to read the
>>archives where subject is all that is initially seen when searching.
>>
>>
>>>if this has already
>>>been implemented isn't there a case for making the
>>>'#project.menu-scheme=directories' the default, and letting those who
>>>need extra flexibilty choose the other option if they need it?
>>
>>Does it actually work the way David suggestd? Seems daft that we don't know!
>
>
> Thinking more about this I can see one drawback: one wouldn't be able
> to control the order in which links appear in menus. I don't think
> this is necessarily a fatal problem though, particularly if the user
> were able to 'freeze' the site structure to the site.xml file.
> One could always hack the order by just renaming the source files,
> 01_foo.xml, 02_morefoo.xml etc. I realise this is probably horrifying
> stuff for programmers... but a lot of website builders like to mess
> around with the usability side of their site structure - nav, nesting
> of sections etc. This would make restructuring very quick and easy.
> There's a lot to be said for using an interface (the OS directory
> structure) which most users are very familiar with.
Yes, that is why, in the resume plugin, the technique is only used for
the list of resume's for people. It makes sense to sort these
alphabetically. But not for most other content.
As for mangling the names to get the right order - it makes me shudder!!
But if users would prefer it then it could be made an option.
>>Here are a couple of advantages (there are others I am sure):
...
> I tend to use SSI's for nav. I also use CSS to filter the output of
> those includes. For instance the developer manuals would be
> class="dev" and in the user site .dev would have a display:none value.
> That's if I needed the the two lists completely merged into user, dev,
> user, dev etc.
The problem with the 'CSS to exclude stuff' approach is that you are
using bandwidth to send informaition that is not being displayed. This
may not be significant in low traffic sites (like my own). But for
something like the Apache sites it mounts up very quickly, that is 1
million lots of 100 extra bytes adds up to lots of bandwidth.
The reduction of bandwitdh use is one of the goals of the project.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
> Because this is no longer Vague - you have made a very concrete
> suggestion. The change of subject makes it much easier to read the
> archives where subject is all that is initially seen when searching.
>
> > if this has already
> > been implemented isn't there a case for making the
> > '#project.menu-scheme=directories' the default, and letting those who
> > need extra flexibilty choose the other option if they need it?
>
> Does it actually work the way David suggestd? Seems daft that we don't know!
Thinking more about this I can see one drawback: one wouldn't be able
to control the order in which links appear in menus. I don't think
this is necessarily a fatal problem though, particularly if the user
were able to 'freeze' the site structure to the site.xml file.
One could always hack the order by just renaming the source files,
01_foo.xml, 02_morefoo.xml etc. I realise this is probably horrifying
stuff for programmers... but a lot of website builders like to mess
around with the usability side of their site structure - nav, nesting
of sections etc. This would make restructuring very quick and easy.
There's a lot to be said for using an interface (the OS directory
structure) which most users are very familiar with.
> > I've read the documentation on linking and I admit I'm yet to be
> > convinced why putting an extra layer of translation into links is
> > advantageous.
>
> Here are a couple of advantages (there are others I am sure):
>
> You have a site with 1000 documents. One of them is in directory A and
> appears in the site navigation structure in a corresponding place.
> However, you eventually realise that the document would be more
> appropriate in a different part of the navigation structure.
> Without site.xml you would have to move the file, but now you have
> broken all the internal links to the original file. Using site.xml you
> simply move it in the navigation structure, but leave it where it is in
> the directory structure.
> ---
>
> You have a file that you want to appear twice in the navigation
> structure. Without site.xml you need to duplicate the content and manage
> two identical files.
>
> ---
>
> Imagine a scenario in which you have 100 files in subdirectories. The
> first 50 are user manuals, the second 50 are developer manuals. The dev
> documents reference the user documents, but not the other way around.
>
> You want to create two sites, one for users (user docs only), one for
> devs (both sets of docs).
>
> Without site.xml how do you do it?
>
I tend to use SSI's for nav. I also use CSS to filter the output of
those includes. For instance the developer manuals would be
class="dev" and in the user site .dev would have a display:none value.
That's if I needed the the two lists completely merged into user, dev,
user, dev etc.
Which is not to say that the site.xml solution isn't inherently
superior. I must admit that part of my interest in Forrest is to look
at different approaches to these sort of problems.
>
> Hope these few examples help illustrate some of the power uses of
> site.xml (doesn't preclude a simple default setting as you describe though).
>
> Ross
>
>
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
> Not quite sure why this is off in a different thread, but: (continuing
> the 'vague issues with Forrest use' discussion)
Because this is no longer Vague - you have made a very concrete
suggestion. The change of subject makes it much easier to read the
archives where subject is all that is initially seen when searching.
> if this has already
> been implemented isn't there a case for making the
> '#project.menu-scheme=directories' the default, and letting those who
> need extra flexibilty choose the other option if they need it?
Does it actually work the way David suggestd? Seems daft that we don't know!
> I've read the documentation on linking and I admit I'm yet to be
> convinced why putting an extra layer of translation into links is
> advantageous.
Here are a couple of advantages (there are others I am sure):
You have a site with 1000 documents. One of them is in directory A and
appears in the site navigation structure in a corresponding place.
However, you eventually realise that the document would be more
appropriate in a different part of the navigation structure.
Without site.xml you would have to move the file, but now you have
broken all the internal links to the original file. Using site.xml you
simply move it in the navigation structure, but leave it where it is in
the directory structure.
---
You have a file that you want to appear twice in the navigation
structure. Without site.xml you need to duplicate the content and manage
two identical files.
---
Imagine a scenario in which you have 100 files in subdirectories. The
first 50 are user manuals, the second 50 are developer manuals. The dev
documents reference the user documents, but not the other way around.
You want to create two sites, one for users (user docs only), one for
devs (both sets of docs).
Without site.xml how do you do it?
---
Hope these few examples help illustrate some of the power uses of
site.xml (doesn't preclude a simple default setting as you describe though).
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
Not quite sure why this is off in a different thread, but: (continuing
the 'vague issues with Forrest use' discussion) if this has already
been implemented isn't there a case for making the
'#project.menu-scheme=directories' the default, and letting those who
need extra flexibilty choose the other option if they need it?
I've read the documentation on linking and I admit I'm yet to be
convinced why putting an extra layer of translation into links is
advantageous.
I have never used it, but i think that that is already
> possible. Look in a forrest.properties from a seed site:
> #project.menu-scheme=tab_attributes
> #project.menu-scheme=directories
>
> The former is the default.
> http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
> Directory-based selection
>
> However site.xml has two functions: menus and linking.
>
> -David
>
--
Paul Bolger
19 Raggatt St
Alice Springs
NT 0870
08 8953 6780
improving menus and linking (Was: vague issues with Forrest use)
Posted by David Crossley <cr...@apache.org>.
Paul Bolger wrote:
> > >> - A simple, intuitive way for non-XMLers to add things to site.xml
> > >
> > > Have you any suggestions about what this may look like?
>
> Not sure how technically possible this is, but how about a directory
> parser which builds the site nav? In other words the user would create
> a directory structure, arrange their source files where they want them
> to appear in the site map, and the parser would build the site
> structure in site.xml as a mirror of that directory structure.
> I realise that this would sacrifice flexibility, but I think a lot of
> users would use a 'quick and dirty' site design method (particularly
> one where rejigging the site structure would be as simple as moving
> the source files).
I have never used it, but i think that that is already
possible. Look in a forrest.properties from a seed site:
#project.menu-scheme=tab_attributes
#project.menu-scheme=directories
The former is the default.
http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
Directory-based selection
However site.xml has two functions: menus and linking.
-David
Re: Where is the line between Forrest and a CMS
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Paul Bolger wrote:
> >So, what is the function of site.xml, if it's not to do the above?
>
> Please be careful with your snipping of mails. The above sentence is
> meaningless in the context of the archives. I've made it worse by moving
> this to a new thread (something we should have done as soon as we
> started discussing this aspect of the original thread).
>
> First let me try to bring some context back for archive readers:
>
> This discussion has been exploring ways of making Forrest easier for new
> users. One suggestion is to provide an interface to manage the site.xml
> file. My own response to this suggestion is that Forrest is an XML
> publishing framework and not a CMS. It should not concern itself with
> how the site structure is managed, only with how it is used to publish
> the content. I suggest that we should focus on integration with CMS
> systems, which are responsible for the management of content. This is
> about where we have got to so far.
In the past we have said that Forrest is not concerned
about editing of source documents, including document
content, and forrest configuration files. Use any text
editor or xml editor.
Forrest's job is to draw the content together, add other
nuggets of information, structure it all, and apply the
theme.
We would rather integrate with proper content management
systems, than try to do that as well.
The editing of Forrest-specific configuration files is a
different matter. As said above, people can use normal
editors for that. The idea sounds good to utilise Cocoon Forms
to make it a specialised part of the Forrest webapp mode.
However i reckon that we need to limit that to our
configuration files. My view is that we should not go
beyond that scope.
> Now, to answer te above question:
>
> site.xml is an internal (to Forrest) representation of the navigation
> structure within a Forrest published content object.
It has multiple purposes: Navigation, link abstraction and
management, table of contents.
> It does not,
> necessarily, bear any relation to the document used in whatever system
> is used to manae the content, it is only relevant to Forrest.
>
> This is akin to our internal XDoc format for documents and provides us
> with a standard document from which we can generate different types of
> content object rendering. For example, we may have the left navigation
> bar in a web site, or the contents list in a wholesite PDF.
>
> OF course, many people actually write the site.xml file and use it as
> the source for their content object as well. But this is not required.
> Cocoon, for example, uses a daisy CMS to manage their content, and
> Burrokeet uses an IMS manifest.
>
> >I'm
> >a bit confused over the definition of CMS being used here - I'm used
> >to it being used to refer to a system which does the lot - user input,
> >site and database management, output formats, conversions, archiving,
> >etc.
>
> Can you point to a CMS that supports the wide range of input and output
> formats that Forrest supports? I certainly can't.
>
> >If Daisy did do this Forrest would be redundant. I've been assuming
> >that, broadly, we are referring to a CMS as an input module, and
> >Forrest as an output module. This separation makes a lot of sense to
> >me.
>
> Yes, that is how I see it too.
I see Forrest as far more than an output module,
and agree that various CMS input modules is the
way to go.
-David
> >I think my original point was that if one wanted to used Forrest as a
> >site generator, and the input files are a directory of Ooo docs, or
> >whatever, it might be appropriate to have a Cocoon forms interface
> >where a user who was intimidated by modifying XML config files could
> >setup the structure of the output site. I'm trying to think in terms
> >of how Forrest could be useful on a small scale. Once people are used
> >to the concepts introduce them to more upscale applications involving
> >databases and Servlets.
>
> Yes, I can see this is a useful tool, but to solve this very problem I
> you could put your OOo files in a Daisy repository, manage the structure
> using their navigation editor and use Forrest to render it like all
> other content, thus you extend the functionality of Daisy without
> duplicating any development effort.
>
> Having said that, I would not object to a contribution like the one you
> suggest. I'm just not sure how current devs would contribute. This has
> come up many times in the past, so far noone has felt a strong enough
> itch, given there are other tools that solve the problem. Of course,
> things change and there are many new devs here now, please don't let me
> put you off, I am sure it would be a useful tool, if you have the itch,
> go scratch it ;-)
>
> Your original suggestion of providing a system to automatically build
> the struture from the directory is a different issue, that can be done
> in just a few lines of code, but does, as you described earlier, have
> considerable drawbacks.
>
> Ross
Re: Where is the line betweenForrest and a CMS (Re: vague issues with Forrest use)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 07, 2005 at 08:33:48PM +0000, Ross Gardler wrote:
> Paul Bolger wrote:
> > So, what is the function of site.xml, if it's not to do the above?
>
> Please be careful with your snipping of mails. The above sentence is
> meaningless in the context of the archives. I've made it worse by moving
> this to a new thread (something we should have done as soon as we
> started discussing this aspect of the original thread).
>
> First let me try to bring some context back for archive readers:
>
> This discussion has been exploring ways of making Forrest easier for new
> users. One suggestion is to provide an interface to manage the site.xml
> file. My own response to this suggestion is that Forrest is an XML
> publishing framework and not a CMS. It should not concern itself with
> how the site structure is managed, only with how it is used to publish
> the content. I suggest that we should focus on integration with CMS
> systems, which are responsible for the management of content. This is
> about where we have got to so far.
I'm very glad this perspective of Forrest is alive and well.
Most documentation systems out there take it upon themselves to
'manage' docs - to be responsible for their storage (in an opaque,
ungreppable DB), editing (through an annoying WYSIWYG editor),
versioning and moving (through clunky web UIs). I can do all that
myself! I LIKE being able to use Subversion or CVS to store docs, to
version docs when and how I like, to use vim or emacs to edit text. On
the output site, I like being able to generate static HTML which can be
themed with Sitemesh and served with any appserver.
Forrest does _just_ the rendering and lets me do the rest how I want to.
There are precious few systems that do this little, and I hope Forrest
never falls for the "we need to become a CMS to be easy to use" argument.
--Jeff
Where is the line betweenForrest and a CMS (Re: vague issues with
Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
> So, what is the function of site.xml, if it's not to do the above?
Please be careful with your snipping of mails. The above sentence is
meaningless in the context of the archives. I've made it worse by moving
this to a new thread (something we should have done as soon as we
started discussing this aspect of the original thread).
First let me try to bring some context back for archive readers:
This discussion has been exploring ways of making Forrest easier for new
users. One suggestion is to provide an interface to manage the site.xml
file. My own response to this suggestion is that Forrest is an XML
publishing framework and not a CMS. It should not concern itself with
how the site structure is managed, only with how it is used to publish
the content. I suggest that we should focus on integration with CMS
systems, which are responsible for the management of content. This is
about where we have got to so far.
Now, to answer te above question:
site.xml is an internal (to Forrest) representation of the navigation
structure within a Forrest published content object. It does not,
necessarily, bear any relation to the document used in whatever system
is used to manae the content, it is only relevant to Forrest.
This is akin to our internal XDoc format for documents and provides us
with a standard document from which we can generate different types of
content object rendering. For example, we may have the left navigation
bar in a web site, or the contents list in a wholesite PDF.
OF course, many people actually write the site.xml file and use it as
the source for their content object as well. But this is not required.
Cocoon, for example, uses a daisy CMS to manage their content, and
Burrokeet uses an IMS manifest.
> I'm
> a bit confused over the definition of CMS being used here - I'm used
> to it being used to refer to a system which does the lot - user input,
> site and database management, output formats, conversions, archiving,
> etc.
Can you point to a CMS that supports the wide range of input and output
formats that Forrest supports? I certainly can't.
> If Daisy did do this Forrest would be redundant. I've been assuming
> that, broadly, we are referring to a CMS as an input module, and
> Forrest as an output module. This separation makes a lot of sense to
> me.
Yes, that is how I see it too.
> I think my original point was that if one wanted to used Forrest as a
> site generator, and the input files are a directory of Ooo docs, or
> whatever, it might be appropriate to have a Cocoon forms interface
> where a user who was intimidated by modifying XML config files could
> setup the structure of the output site. I'm trying to think in terms
> of how Forrest could be useful on a small scale. Once people are used
> to the concepts introduce them to more upscale applications involving
> databases and Servlets.
Yes, I can see this is a useful tool, but to solve this very problem I
you could put your OOo files in a Daisy repository, manage the structure
using their navigation editor and use Forrest to render it like all
other content, thus you extend the functionality of Daisy without
duplicating any development effort.
Having said that, I would not object to a contribution like the one you
suggest. I'm just not sure how current devs would contribute. This has
come up many times in the past, so far noone has felt a strong enough
itch, given there are other tools that solve the problem. Of course,
things change and there are many new devs here now, please don't let me
put you off, I am sure it would be a useful tool, if you have the itch,
go scratch it ;-)
Your original suggestion of providing a system to automatically build
the struture from the directory is a different issue, that can be done
in just a few lines of code, but does, as you described earlier, have
considerable drawbacks.
Ross
Re: vague issues with Forrest use
Posted by Paul Bolger <pb...@gmail.com>.
So, what is the function of site.xml, if it's not to do the above? I'm
a bit confused over the definition of CMS being used here - I'm used
to it being used to refer to a system which does the lot - user input,
site and database management, output formats, conversions, archiving,
etc.
If Daisy did do this Forrest would be redundant. I've been assuming
that, broadly, we are referring to a CMS as an input module, and
Forrest as an output module. This separation makes a lot of sense to
me.
I think my original point was that if one wanted to used Forrest as a
site generator, and the input files are a directory of Ooo docs, or
whatever, it might be appropriate to have a Cocoon forms interface
where a user who was intimidated by modifying XML config files could
setup the structure of the output site. I'm trying to think in terms
of how Forrest could be useful on a small scale. Once people are used
to the concepts introduce them to more upscale applications involving
databases and Servlets.
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>Actually, I should say, I do think that partnering wth a CMS that does
>>this stuff is the way to go. Forrest should not attempt to become a CMS.
>
>
> My apologies for forking this discussion somewhat.
>
> I was more referring to using an Xforms or Cocoon forms interface to
> control linking, input document types, and site navigation.
Yes, and that is the function of a Content Management System, Forrest is
an XML publishing framework not a CMS.
The Daisy plugin already provides full control over linking and site
navigation (not document types). The proposed Lenya plugin will do even
more if we ever get it off the ground (Lenya handles different doc types).
It doesn't seem to make sense to me to duplicate this work, instead we
should focus on a tighter integration with CMS systems. The Daisy plugin
shows the way (and it is *really* easy).
Ross
Re: vague issues with Forrest use
Posted by Paul Bolger <pb...@gmail.com>.
> Actually, I should say, I do think that partnering wth a CMS that does
> this stuff is the way to go. Forrest should not attempt to become a CMS.
My apologies for forking this discussion somewhat.
I was more referring to using an Xforms or Cocoon forms interface to
control linking, input document types, and site navigation.
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Paul Bolger wrote:
...
>> Point taken. Maybe this is another red herring, but would an Xforms
>> front end for site.xml be possible?
>
>
> Yes (or rather yes to Cocoon Forms). I've been thinking about this, on
> and off for a long time, but never really got started on it. The main
> problem is that I've so far failed to get Cocoon Forms running alongside
> Forrest.
>
> I do think this is the way to go since it would be self hosting within
> Forrest itself.
Actually, I should say, I do think that partnering wth a CMS that does
this stuff is the way to go. Forrest should not attempt to become a CMS.
For example, the Cocoon docs for 2.1.8 are (staging publication is at
[1]) is published from a Daisy CMS system [2]
[1] http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html
[2] http://cocoon.zones.apache.org/daisy/legacydocs/654.html
We have plans to do an even tighter integration with Lenya, but that is
not moving forward at any great pace right now.
Ross
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>I agree, to an extent, with your observations. However, are you aware
>>that Eclipse can be deployed with a specific set of plugins (and minus
>>all the IDE stuff). This makes it reasonably lightweight and highly
>>focussed on a specific task.
>
>
> I think if there were some way to avoid the online software
> installation process (which in my case always seems to end up timing
> out half way through the procedure, or not being able to find some of
> the components) my Eclipse experiences may have been better.
That's what an Eclpse RCP (Rich Client Platform) applcation is. Eclipse
is an application framework, it just happens to be most commonly used as
for development application.
> Point taken. Maybe this is another red herring, but would an Xforms
> front end for site.xml be possible?
Yes (or rather yes to Cocoon Forms). I've been thinking about this, on
and off for a long time, but never really got started on it. The main
problem is that I've so far failed to get Cocoon Forms running alongside
Forrest.
I do think this is the way to go since it would be self hosting within
Forrest itself.
Ross
Re: vague issues with Forrest use
Posted by Paul Bolger <pb...@gmail.com>.
> I agree, to an extent, with your observations. However, are you aware
> that Eclipse can be deployed with a specific set of plugins (and minus
> all the IDE stuff). This makes it reasonably lightweight and highly
> focussed on a specific task.
I think if there were some way to avoid the online software
installation process (which in my case always seems to end up timing
out half way through the procedure, or not being able to find some of
the components) my Eclipse experiences may have been better.
Obviously that's not your problem, but I it may be useful to bear in
mind that Java developers tend to have tools like Eclipse installed
and ready, while people who are looking for a website generator are
likely to be a lot less familiar with that sort of software. We should
be looking at ways of making the site setup as simple as possible at
the entry level.
> I too like JEdit, but it is not possible to build a rich client
> application in JEdit, it's an editor not an applicaiton framework. I too
> use it a great deal for editing XML, but I can't see it solving the
> problems of the user who can't find their way around out XML
> configuration files.
>
> Ross
>
Point taken. Maybe this is another red herring, but would an Xforms
front end for site.xml be possible?
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>>>- A simple, intuitive way for non-XMLers to add things to site.xml
>>>
>>>
>>>Have you any suggestions about what this may look like?
>
>
> Not sure how technically possible this is, but how about a directory
> parser which builds the site nav?
I replied to this in the new thread David created.
>>No, unfortunately I haven't thought too hard on it and I have limited
>>coding skills to even know what can be done. I just know that as soon
>>as I try to explain to coworkers how I add things their eyes sort of
>>glaze and they wander off to do something else.
>>
>>
>>>Have you taken a look at the Eclipse plugin? This is a (very early
>>>development) of a GUI application for editing of things like site.xml.
>>>It works, but is a long way from perfect.
>
>
> Personally I don't like Eclipse much, takes ages to start, always
> seems to be missing some plugin which takes half a day to locate,
> slow. Would a Jedit plugin be possible? I use Jedit a lot as an HTML
> editor - largely because it has some great helper plugins like Xilize
> - and it works fine even on my slowest machine.
I agree, to an extent, with your observations. However, are you aware
that Eclipse can be deployed with a specific set of plugins (and minus
all the IDE stuff). This makes it reasonably lightweight and highly
focussed on a specific task.
I too like JEdit, but it is not possible to build a rich client
application in JEdit, it's an editor not an applicaiton framework. I too
use it a great deal for editing XML, but I can't see it solving the
problems of the user who can't find their way around out XML
configuration files.
Ross
Re: vague issues with Forrest use
Posted by Paul Bolger <pb...@gmail.com>.
> >> - A simple, intuitive way for non-XMLers to add things to site.xml
> >
> >
> > Have you any suggestions about what this may look like?
Not sure how technically possible this is, but how about a directory
parser which builds the site nav? In other words the user would create
a directory structure, arrange their source files where they want them
to appear in the site map, and the parser would build the site
structure in site.xml as a mirror of that directory structure.
I realise that this would sacrifice flexibility, but I think a lot of
users would use a 'quick and dirty' site design method (particularly
one where rejigging the site structure would be as simple as moving
the source files).
> No, unfortunately I haven't thought too hard on it and I have limited
> coding skills to even know what can be done. I just know that as soon
> as I try to explain to coworkers how I add things their eyes sort of
> glaze and they wander off to do something else.
>
> >
> > Have you taken a look at the Eclipse plugin? This is a (very early
> > development) of a GUI application for editing of things like site.xml.
> > It works, but is a long way from perfect.
Personally I don't like Eclipse much, takes ages to start, always
seems to be missing some plugin which takes half a day to locate,
slow. Would a Jedit plugin be possible? I use Jedit a lot as an HTML
editor - largely because it has some great helper plugins like Xilize
- and it works fine even on my slowest machine.
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
Addi wrote:
> Ross Gardler wrote:
...
> Well I do have an itch for stupid clear docs. I did submit the
> beginnings (mostly completed) of stupid clear docs for installing
> Forrest - FOR-699 (http://issues.apache.org/jira/browse/FOR-699).
Oh dear, I see we have left that languishing in the issue tracker. Once
again we have slacked on the documentation contributions - sorry (I've
upped the priority and put it into the 0.8 release) Hopefully someone
will get time to review and commit soon.
> The
> way I envision documentation though is to actually have a cohesive,
> comprehensive manual. I know this has been talked about before on the
> list and we were looking at perhaps really hammering this out at
> ApacheCon in San Diego, but it looks like a documentathon may not really
> happen since not many will make it (I'm now leaning towards not being
> able to go either).
A topic for a Forrest Friday?
> So perhaps, for those of us who are interested, we should start
> discussing a larger plan for documentation and the creation of a new
> user "Intro to Forrest" that is basic and step-by-step. Of course this
> kind of project can be tricky since Forrest dev moves so quickly.
> Anyway, as we move closer to 1.0 release we do need to make the docs
> easier to use and understand for users who are brand new to the whole
> concept of what Forrest does and how.
Ferdinand has done some groundwork on this. Lets hope he soon finds the
time to come back here.
> As for the two main things on docs I listed above, I still don't grasp
> Forrestbot well enough to feel like I could write the docs well. I can
> make it work but I don't have the time to really understand what exactly
> it is doing. If you look at the Forrestbot doc we have now, I put in
> lots of fix me's on things I don't get.
Any contribution to existing docs is an improvement, sure the goal is
the "idiot guide", but lots of small steps are as good as one large steps.
Re: vague issues with Forrest use
Posted by Addi <ad...@rocktreesky.com>.
Ross Gardler wrote:
> Addi wrote:
>
>> Hm, well I don't know what resources the Apache projects are dealing
>> with but I have not implemented Forrest at my work (other than for me
>> to play with) because I am the only person who understands anything
>> about XML. The biggest hurdles I see at my office are site.xml and
>> the actual documents with deployment also being a secondary issue.
>> They are hurdles because I can't be the only person who knows how to
>> use it. It isn't efficient if I'm the only one who can add docs and
>> do anything at all with it. Now that I have spent time with Forrest
>> I know there are some tools to help me with those issues. So *for my
>> use case situation* things that would make Forrest more viable:
>>
>> - A simple, intuitive way for non-XMLers to add things to site.xml
>
>
> Have you any suggestions about what this may look like?
No, unfortunately I haven't thought too hard on it and I have limited
coding skills to even know what can be done. I just know that as soon
as I try to explain to coworkers how I add things their eyes sort of
glaze and they wander off to do something else.
>
> Have you taken a look at the Eclipse plugin? This is a (very early
> development) of a GUI application for editing of things like site.xml.
> It works, but is a long way from perfect.
I have installed Eclipse but never seem to have time to play around with
it or our plugins. We don't have any need for Eclipse so it doesn't fit
into any other work I do. I'll try to make time to check it out.
>
> The biggest hurdle to its use is that it requires an Eclipse
> installation, although it is possible to build a standalone
> application for it.
>
>> - Emphasis and stupid clear instructions on document plugins
>> (DocBook, OpenOffice)
>> - Emphasis and stupid clear instructions on Forrestbot
>
> >
>
>> By stupid clear, I mean so that someone with little XML and Forrest
>> experience can understand at least half of what you are saying and
>> not be intimidated to at least try.
>
>
> Yes, docs are important and are the hardest things to create. The
> problem is that to write them you need to have the inclination to make
> them "stupid clear", unfortunately most of the devs don't have such a
> drive.
>
> All help is welcome, and newcomers to Forrest are in the best position
> to write these stupid clear docs - with help and guidance from the
> devs of course.
>
> Ross
Well I do have an itch for stupid clear docs. I did submit the
beginnings (mostly completed) of stupid clear docs for installing
Forrest - FOR-699 (http://issues.apache.org/jira/browse/FOR-699). The
way I envision documentation though is to actually have a cohesive,
comprehensive manual. I know this has been talked about before on the
list and we were looking at perhaps really hammering this out at
ApacheCon in San Diego, but it looks like a documentathon may not really
happen since not many will make it (I'm now leaning towards not being
able to go either).
So perhaps, for those of us who are interested, we should start
discussing a larger plan for documentation and the creation of a new
user "Intro to Forrest" that is basic and step-by-step. Of course this
kind of project can be tricky since Forrest dev moves so quickly.
Anyway, as we move closer to 1.0 release we do need to make the docs
easier to use and understand for users who are brand new to the whole
concept of what Forrest does and how.
As for the two main things on docs I listed above, I still don't grasp
Forrestbot well enough to feel like I could write the docs well. I can
make it work but I don't have the time to really understand what exactly
it is doing. If you look at the Forrestbot doc we have now, I put in
lots of fix me's on things I don't get.
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
Addi wrote:
> Hm, well I don't know what resources the Apache projects are dealing
> with but I have not implemented Forrest at my work (other than for me to
> play with) because I am the only person who understands anything about
> XML. The biggest hurdles I see at my office are site.xml and the actual
> documents with deployment also being a secondary issue. They are
> hurdles because I can't be the only person who knows how to use it. It
> isn't efficient if I'm the only one who can add docs and do anything at
> all with it. Now that I have spent time with Forrest I know there are
> some tools to help me with those issues. So *for my use case situation*
> things that would make Forrest more viable:
>
> - A simple, intuitive way for non-XMLers to add things to site.xml
Have you any suggestions about what this may look like?
Have you taken a look at the Eclipse plugin? This is a (very early
development) of a GUI application for editing of things like site.xml.
It works, but is a long way from perfect.
The biggest hurdle to its use is that it requires an Eclipse
installation, although it is possible to build a standalone application
for it.
> - Emphasis and stupid clear instructions on document plugins (DocBook,
> OpenOffice)
> - Emphasis and stupid clear instructions on Forrestbot
>
> By stupid clear, I mean so that someone with little XML and Forrest
> experience can understand at least half of what you are saying and not
> be intimidated to at least try.
Yes, docs are important and are the hardest things to create. The
problem is that to write them you need to have the inclination to make
them "stupid clear", unfortunately most of the devs don't have such a drive.
All help is welcome, and newcomers to Forrest are in the best position
to write these stupid clear docs - with help and guidance from the devs
of course.
Ross
Re: vague issues with Forrest use
Posted by Addi <ad...@rocktreesky.com>.
Hm, well I don't know what resources the Apache projects are dealing
with but I have not implemented Forrest at my work (other than for me to
play with) because I am the only person who understands anything about
XML. The biggest hurdles I see at my office are site.xml and the actual
documents with deployment also being a secondary issue. They are
hurdles because I can't be the only person who knows how to use it. It
isn't efficient if I'm the only one who can add docs and do anything at
all with it. Now that I have spent time with Forrest I know there are
some tools to help me with those issues. So *for my use case situation*
things that would make Forrest more viable:
- A simple, intuitive way for non-XMLers to add things to site.xml
- Emphasis and stupid clear instructions on document plugins (DocBook,
OpenOffice)
- Emphasis and stupid clear instructions on Forrestbot
By stupid clear, I mean so that someone with little XML and Forrest
experience can understand at least half of what you are saying and not
be intimidated to at least try.
Anyway, those are my knee-jerk thoughts in response. Hope I'm not
off-base of your point.
- Addi
David Crossley wrote:
>(Sorry, this got too long but i reckon it is important.)
>
>As you know, various people are using Forrest.
>For some see: http://forrest.apache.org/live-sites.html
>
>We can only presume they are well aware of what they are doing.
>They have chosen to use the pre-1.0 software. They will all
>have someone who knows how to run forrest, and knows to ask
>questions on the forrest user mailing list if they get stuck
>with upgrading, usage, installation, etc.
>
>However, i wonder if we are doing such a good job with
>making software that is usable now, even though it is a
>long way off being a 1.0 release, that some people/projects
>are getting themselves into hot water by depending on it
>before it is actually ready.
>
>We need to emphasise in our documentation, and in the
>release announcements, that this is pre-1.0 software.
>Yet still we can show that it is certainly usable for
>those who are prepared to move with it. We use it.
>
>I am particularly concerned about certain meta-projects at
>the Apache Software Foundation. For example, xml.apache.org
>and incubator.apache.org
>
>These places decided to use Forrest long ago, IIRC at 0.5
>
>However, they do not now have people who understand how to
>use it, how to upgrade it, how to get around its quirks.
>Especially at Apache Incubator. The people are there
>to introduce new projects, new people, and to write and
>publish documentation.
>
>I don't quite know the history of Incubator, but i presume
>that people got excited about eating Apache dogfood and
>decided to go with Forrest. Perhaps the original proponents
>moved on. Now it seems that people are not happy with it,
>finding it cumbersome. I have heard some people say
>that they can't actually point to any particular thing.
>Mostly it is just silence and lack of use.
>
>Recently it was proposed that Forrest might be a solution
>at another part of ASF Infrastructure. That met with a lot
>of criticism, yet there was not a lot of concrete feedback.
>
>Over-dedicated volunteers like me and Ross, tend to go and
>help such places. However that is not sustainable.
>
>I don't know what to do about this. At the least
>i thought to send this mail because the Forrest PMC
>should be aware that there is something happening that
>could be damaging for our project. People are gumbling.
>
>We need to look at ways of making it more user-friendly.
>It is obviously not easy or the incubator.apache.org
>issues would not arise.
>
>Perhaps the problem is documentation for how to install
>and use forrest. These projects have a smattering
>of their own documentation for how to use it, but often
>it is poor and way out-of-date. Perhaps we need to
>write a document focussed on use of Forrest at Apache.
>
>Perhaps we need to actively go out and ask those
>Apache projects that use Forrest, what they see as
>the hindrance. It seems to me that people must be
>grumbling but not actually saying that they have issues
>or perhaps not being able to define the issues.
>
>-David
>
>
>
>
>
Re: machine spec for forrest run
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 03-11-2005 a las 12:25 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> >
> >>Kevin wrote:
> >>
> >>>Does anyone have a performance problem using forrest run.
> >>>My test is on the main index page of seed-v2.
> >>
> >>I'm not using views 2, so cannot comment directly. However, it is known
> >>that there are lots of performance issues with views 2.
> >
> >
> > Why? If you have said v1 than you get a +1 from me because of the
> > extensive usage of xinclude which is not cacheable in v1. In v2 I do not
> > use xinclude at all (beside the default usage from main pipes of forrest
> > core).
>
> OK, maybe I spoke too soon. But I do think there is much happening in
> XSL that need not happen in a memory exhaustive approach. This is not a
> criticism of your work, merely an observation of how it can be improved
> with respect to performance.
>
Agree
> >>The tentative
> >>plan is to move much of the heavy XSL processing into Java components.
> >>Most of the stuff that is done to bring the contracts together, for
> >>example, need not be done with processor and memory intensive XSL
> >>transforms.
> >
> >
> > Actually I debugged it a bit and what I see is that the locationmap
> > lookups are taking ages. Since v2 is totally based on the lm that may
> > have introduced some new performance issues.
>
> Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711
>
> > Sorry for not being faster in providing a transformer for overcome the
> > xsl aggregation but I am ATM a wee bit handicapped without an internet
> > connection and moving all v2 stuff to their final locations.
>
> Come on Thorsten, you know there is no need to apologise. We don't
> expect *you* to do it, I only raise it here so that everyone is aware of
> things that need to be done and therefore how they can contribute.
>
Actually I am sorry even if I do not have to. ;-)
You are right in what you just pointed out and thanks for doing it. I
have a half baked transformer on my harddrive but then started to play
around with the theme switching stuff, run into the resource problematic
and the moving of resources.
All this work that I started on the same time is holding up the people
to go on with their work (e.g. xhtml2). ...
> >>In other words, performance has not been addressed yet.
> >
> >
> > That is not true! Like stated above I ripped out the xinclude stuff that
> > was pointed out to be the worst part for performance.
>
> Sorry, performance is being addressed, please help ;-)
>
+1
I started v2 to really address this performance issues but like Ross
stated: Please help.
> Ross
thx Ross
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: machine spec for forrest run
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
>
>>Kevin wrote:
>>
>>>Does anyone have a performance problem using forrest run.
>>>My test is on the main index page of seed-v2.
>>
>>I'm not using views 2, so cannot comment directly. However, it is known
>>that there are lots of performance issues with views 2.
>
>
> Why? If you have said v1 than you get a +1 from me because of the
> extensive usage of xinclude which is not cacheable in v1. In v2 I do not
> use xinclude at all (beside the default usage from main pipes of forrest
> core).
OK, maybe I spoke too soon. But I do think there is much happening in
XSL that need not happen in a memory exhaustive approach. This is not a
criticism of your work, merely an observation of how it can be improved
with respect to performance.
>>The tentative
>>plan is to move much of the heavy XSL processing into Java components.
>>Most of the stuff that is done to bring the contracts together, for
>>example, need not be done with processor and memory intensive XSL
>>transforms.
>
>
> Actually I debugged it a bit and what I see is that the locationmap
> lookups are taking ages. Since v2 is totally based on the lm that may
> have introduced some new performance issues.
Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711
> Sorry for not being faster in providing a transformer for overcome the
> xsl aggregation but I am ATM a wee bit handicapped without an internet
> connection and moving all v2 stuff to their final locations.
Come on Thorsten, you know there is no need to apologise. We don't
expect *you* to do it, I only raise it here so that everyone is aware of
things that need to be done and therefore how they can contribute.
>>In other words, performance has not been addressed yet.
>
>
> That is not true! Like stated above I ripped out the xinclude stuff that
> was pointed out to be the worst part for performance.
Sorry, performance is being addressed, please help ;-)
Ross
Re: machine spec for forrest run
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> Kevin wrote:
> > Does anyone have a performance problem using forrest run.
> > My test is on the main index page of seed-v2.
>
> I'm not using views 2, so cannot comment directly. However, it is known
> that there are lots of performance issues with views 2.
Why? If you have said v1 than you get a +1 from me because of the
extensive usage of xinclude which is not cacheable in v1. In v2 I do not
use xinclude at all (beside the default usage from main pipes of forrest
core).
> The tentative
> plan is to move much of the heavy XSL processing into Java components.
> Most of the stuff that is done to bring the contracts together, for
> example, need not be done with processor and memory intensive XSL
> transforms.
Actually I debugged it a bit and what I see is that the locationmap
lookups are taking ages. Since v2 is totally based on the lm that may
have introduced some new performance issues.
Sorry for not being faster in providing a transformer for overcome the
xsl aggregation but I am ATM a wee bit handicapped without an internet
connection and moving all v2 stuff to their final locations.
> In other words, performance has not been addressed yet.
That is not true! Like stated above I ripped out the xinclude stuff that
was pointed out to be the worst part for performance.
> Ross
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: machine spec for forrest run
Posted by Ross Gardler <rg...@apache.org>.
Kevin wrote:
> Does anyone have a performance problem using forrest run.
> My test is on the main index page of seed-v2.
I'm not using views 2, so cannot comment directly. However, it is known
that there are lots of performance issues with views 2. The tentative
plan is to move much of the heavy XSL processing into Java components.
Most of the stuff that is done to bring the contracts together, for
example, need not be done with processor and memory intensive XSL
transforms.
In other words, performance has not been addressed yet.
Ross
machine spec for forrest run
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Does anyone have a performance problem using forrest run.
My test is on the main index page of seed-v2.
It is very slow for me over 2 minutes for the first
http://localhost:8888/index.html Over 1 minute to refresh
this page.
I use a 1.2G machine with 512M memory running Linux
Fedora Core 3. CPU hits 100% about half memory used
and no swapping.
Any tips on speeding up forrest run I have tried commenting
out the debug statement in forrest.properties
Can I switch off all the debug on the console maybe that
will help?
Thanks,
Kevin
Re: views v2 corner images
Posted by Thorsten Scherler <th...@apache.org>.
Hi Kevin,
I played around with that yesterday. I run into the same problem like
you describe that the images are not generated with forrest site. :(
Actually forrest run works like a charm but the static export not.
Actually that is not the only thing that is working probably in forrest
site. The ls.contracts.xml as well is not being created.
I do not know ATM why, but we need to fix this ASAP.
salu2
El lun, 31-10-2005 a las 18:13 +0000, Kevin escribió:
> org.apache.forrest.plugin.output.themer corner images
>
> I have made some progress with this. My understanding is that:
>
> 1) default corner images are in pelt.screen.css
> 2) these could be overridden inline by branding-theme-profiler.ft
>
> ====
>
> 1)
> I will raise an enhancement jira with a new pelt.screen.css that
> references corner images with hex values so the old skinconf is
> not used ie:
> #header .round-top-left-small {
> background-image: url(../skin/images/rc-t-l-5-X294563-X4a6d8c-
> X4a6d8c.png);
> background-repeat: no-repeat;
> background-position: top left;
> }
>
> plus
>
> rcX.svg.xslt and corner-importsX.svg.xslt
> that deal with hex values rather than skinconf names
> to go in main/webapp/skins/common/images as a fallback
>
> Note:
> an update to resouces.xmap to match this request is needed:
> <map:match pattern="skin/images**/*c-*-*-*-X*-X*-X*.png">
> <map:call resource="read-svg2png-corner-resource">
> <map:parameter name="path" value="images/{1}" />
> <map:parameter name="name" value="{2}cX" />
> <map:parameter name="orientation-tb" value="{3}"/>
> <map:parameter name="orientation-lr" value="{4}"/>
> <map:parameter name="size" value="{5}"/>
> <map:parameter name="bg-color-name" value="{6}"/>
> <map:parameter name="stroke-color-name" value="{7}"/>
> <map:parameter name="fg-color-name" value="{8}"/>
> </map:call>
> not sure if this goes in the core it would be a fallback from plugin
> resources.xmap if the request wasn't matched?
>
> Also sitemap.xmap used lm for *.css matches not sure how it should be
> used here. So I let it go to resources.xmap for above testing.
>
> 2)
> My old work in this area fitted well with the branding-theme-profiler.ft
> I have attached my version for comment. The only minor change to pelt.fv
> was adding
> <colors>
> <!-- as before -->
> </colors>
> root so I could work there and let the <color> matches work as before.
>
> ====
>
> Problem:
> Item (2) xslt will work out of the box with the change to pelt.fv
> but again I've tripped up as these inline corner images aren't
> crawled and generated :(
>
> Looking at the generated source the hex URLs are correctly created
> and inline. This is a worrying me as 'forrest site' user.
> (Well I haven't actually done any authoring yet, learning how it works
> is more fun :)
>
> If (1) works fine when pelt.screen.css is crawled. Why does (2) fail.
> This is the same problem as my last attempt in views v1.
> Am I missing something?
>
> Kevin
>
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
views v2 corner images
Posted by Kevin <fo...@kegcl.demon.co.uk>.
org.apache.forrest.plugin.output.themer corner images
I have made some progress with this. My understanding is that:
1) default corner images are in pelt.screen.css
2) these could be overridden inline by branding-theme-profiler.ft
====
1)
I will raise an enhancement jira with a new pelt.screen.css that
references corner images with hex values so the old skinconf is
not used ie:
#header .round-top-left-small {
background-image: url(../skin/images/rc-t-l-5-X294563-X4a6d8c-
X4a6d8c.png);
background-repeat: no-repeat;
background-position: top left;
}
plus
rcX.svg.xslt and corner-importsX.svg.xslt
that deal with hex values rather than skinconf names
to go in main/webapp/skins/common/images as a fallback
Note:
an update to resouces.xmap to match this request is needed:
<map:match pattern="skin/images**/*c-*-*-*-X*-X*-X*.png">
<map:call resource="read-svg2png-corner-resource">
<map:parameter name="path" value="images/{1}" />
<map:parameter name="name" value="{2}cX" />
<map:parameter name="orientation-tb" value="{3}"/>
<map:parameter name="orientation-lr" value="{4}"/>
<map:parameter name="size" value="{5}"/>
<map:parameter name="bg-color-name" value="{6}"/>
<map:parameter name="stroke-color-name" value="{7}"/>
<map:parameter name="fg-color-name" value="{8}"/>
</map:call>
not sure if this goes in the core it would be a fallback from plugin
resources.xmap if the request wasn't matched?
Also sitemap.xmap used lm for *.css matches not sure how it should be
used here. So I let it go to resources.xmap for above testing.
2)
My old work in this area fitted well with the branding-theme-profiler.ft
I have attached my version for comment. The only minor change to pelt.fv
was adding
<colors>
<!-- as before -->
</colors>
root so I could work there and let the <color> matches work as before.
====
Problem:
Item (2) xslt will work out of the box with the change to pelt.fv
but again I've tripped up as these inline corner images aren't
crawled and generated :(
Looking at the generated source the hex URLs are correctly created
and inline. This is a worrying me as 'forrest site' user.
(Well I haven't actually done any authoring yet, learning how it works
is more fun :)
If (1) works fine when pelt.screen.css is crawled. Why does (2) fail.
This is the same problem as my last attempt in views v1.
Am I missing something?
Kevin
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
...
>>>I don't know what to do about this. At the least
>>>i thought to send this mail because the Forrest PMC
>>>should be aware that there is something happening that
>>>could be damaging for our project. People are gumbling.
>>
>>We need to encourage them to grumble on ur users lists not on unrelated
>>lists. I was not aware, until comments were made on other lists, of any
>>problems within Incubator (interestingly there were positive commets
>>from the XML people).
>
>
> That doesn't seem to happen. Many of the grumbles
> do happen on other lists.
Then an education drive is needed, we can't help users if we can't hear
them. It is not reasonable to expect us to listen to their lists.
>>>We need to look at ways of making it more user-friendly.
>>>It is obviously not easy or the incubator.apache.org
>>>issues would not arise.
>>
>>I am going to join the incubator list next week and try and work out
>>what is happening.
>
>
> I started:
> http://marc.theaimsgroup.com/?t=113108607500002
> "simplifying the generation of Incubator website"
> One major issue has already been identified. I will start
> a separate thread here on forrest-dev for that.
I've taken an unexpected working holiday, probably won't join in till
next week now, however, I will be there and I am monitoring tis list.
Ross
Re: vague issues with Forrest use
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >
> >I don't quite know the history of Incubator, but i presume
> >that people got excited about eating Apache dogfood and
> >decided to go with Forrest. Perhaps the original proponents
> >moved on. Now it seems that people are not happy with it,
> >finding it cumbersome. I have heard some people say
> >that they can't actually point to any particular thing.
> >Mostly it is just silence and lack of use.
>
> Well, I am moving towards Forrest being able to generate/host multiple
> related sites. I'm thinking that Incubator is the place to work on this.
>
> Wouyld you think this is a good idea.
No. That is not their problem. The top-level
Apache Incubator website is totally separate from
each incubating project. The projects each have their
own SVN and website generation procedures. Some of them
use forrest, some use maven.
> >I don't know what to do about this. At the least
> >i thought to send this mail because the Forrest PMC
> >should be aware that there is something happening that
> >could be damaging for our project. People are gumbling.
>
> We need to encourage them to grumble on ur users lists not on unrelated
> lists. I was not aware, until comments were made on other lists, of any
> problems within Incubator (interestingly there were positive commets
> from the XML people).
That doesn't seem to happen. Many of the grumbles
do happen on other lists.
> >We need to look at ways of making it more user-friendly.
> >It is obviously not easy or the incubator.apache.org
> >issues would not arise.
>
> I am going to join the incubator list next week and try and work out
> what is happening.
I started:
http://marc.theaimsgroup.com/?t=113108607500002
"simplifying the generation of Incubator website"
One major issue has already been identified. I will start
a separate thread here on forrest-dev for that.
-David
> >Perhaps the problem is documentation for how to install
> >and use forrest. These projects have a smattering
> >of their own documentation for how to use it, but often
> >it is poor and way out-of-date. Perhaps we need to
> >write a document focussed on use of Forrest at Apache.
>
> +1
>
> >Perhaps we need to actively go out and ask those
> >Apache projects that use Forrest, what they see as
> >the hindrance. It seems to me that people must be
> >grumbling but not actually saying that they have issues
> >or perhaps not being able to define the issues.
>
> +100
>
> Ross
Re: vague issues with Forrest use
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> (Sorry, this got too long but i reckon it is important.)
>
> As you know, various people are using Forrest.
> For some see: http://forrest.apache.org/live-sites.html
>
> We can only presume they are well aware of what they are doing.
> They have chosen to use the pre-1.0 software. They will all
> have someone who knows how to run forrest, and knows to ask
> questions on the forrest user mailing list if they get stuck
> with upgrading, usage, installation, etc.
>
> However, i wonder if we are doing such a good job with
> making software that is usable now, even though it is a
> long way off being a 1.0 release, that some people/projects
> are getting themselves into hot water by depending on it
> before it is actually ready.
>
> We need to emphasise in our documentation, and in the
> release announcements, that this is pre-1.0 software.
> Yet still we can show that it is certainly usable for
> those who are prepared to move with it. We use it.
+1
> I am particularly concerned about certain meta-projects at
> the Apache Software Foundation. For example, xml.apache.org
> and incubator.apache.org
>
> These places decided to use Forrest long ago, IIRC at 0.5
>
> However, they do not now have people who understand how to
> use it, how to upgrade it, how to get around its quirks.
> Especially at Apache Incubator. The people are there
> to introduce new projects, new people, and to write and
> publish documentation.
>
> I don't quite know the history of Incubator, but i presume
> that people got excited about eating Apache dogfood and
> decided to go with Forrest. Perhaps the original proponents
> moved on. Now it seems that people are not happy with it,
> finding it cumbersome. I have heard some people say
> that they can't actually point to any particular thing.
> Mostly it is just silence and lack of use.
Well, I am moving towards Forrest being able to generate/host multiple
related sites. I'm thinking that Incubator is the place to work on this.
Wouyld you think this is a good idea.
> Recently it was proposed that Forrest might be a solution
> at another part of ASF Infrastructure. That met with a lot
> of criticism, yet there was not a lot of concrete feedback.
>
> Over-dedicated volunteers like me and Ross, tend to go and
> help such places. However that is not sustainable.
You are correct, it is not sustainable.
I am re-examining my involvement with this new meta-project. My time
will be better spent on stabalising Forrest and understanding the
"unspoken" problems at Incubator.
> I don't know what to do about this. At the least
> i thought to send this mail because the Forrest PMC
> should be aware that there is something happening that
> could be damaging for our project. People are gumbling.
We need to encourage them to grumble on ur users lists not on unrelated
lists. I was not aware, until comments were made on other lists, of any
problems within Incubator (interestingly there were positive commets
from the XML people).
> We need to look at ways of making it more user-friendly.
> It is obviously not easy or the incubator.apache.org
> issues would not arise.
I am going to join the incubator list next week and try and work out
what is happening.
> Perhaps the problem is documentation for how to install
> and use forrest. These projects have a smattering
> of their own documentation for how to use it, but often
> it is poor and way out-of-date. Perhaps we need to
> write a document focussed on use of Forrest at Apache.
+1
> Perhaps we need to actively go out and ask those
> Apache projects that use Forrest, what they see as
> the hindrance. It seems to me that people must be
> grumbling but not actually saying that they have issues
> or perhaps not being able to define the issues.
+100
Ross