You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2006/01/02 07:48:35 UTC
New skin: Coat
I've been wanting to create a skin for Forrest that looks like that at
http://www.apache.org for some time. Mostly because the default Forrest
skins are, well "old".
The recent thread on the incubator list discussing Forrest as a tool has
finally prompted me into action (congrats to anyone deliberately
provoking us to make this happen ;-). I've built the Incubator site
using it.
It's not perfect, but a a very good start. Really this should be done in
the dispatcher, especially since most of the work is removing stuff from
pelt and changing the CSS. However, we need this now, at least as a demo
of a good clean skin. Besides, it only took about an hour and a half.
You can view the prototype skin at:
http://people.apache.org/~rgardler/testingGround/coat/
Ross
Re: The future (was Re: New skin: Coat)
Posted by Ferdinand Soethe <fe...@apache.org>.
Paul Bolger wrote:
> Maybe the best place to start would for you to clarify what the
> JavaScript in the current menu system actually does.
That is very simple. (Finally something I can do :-))
In the current menu system JavaScript (just one function to be exact)
is responsible for the apparent opening of submenus when you click a
parent menu item.
Apparent because JS is really only manipulating css-properties to
change the twisty-icon in front of the parent menu item and show/hide
the div-container with the submenuitems.
--
Ferdinand Soethe
Re: The future (was Re: New skin: Coat)
Posted by Paul Bolger <pb...@gmail.com>.
Hi Ferdinand
Thanks for offering. As you may be aware the 'news' contract has
developed somewhat since this conversation began, see Helena's RSS
contribution: FOR-784. What I was originally thinking of was a more
generic indexer, a contract which could parse a directory, or
directory tree, (or content by other criteria, but selecting a
directory sounds like an easy place to start) and output a list of
links to documents in that directory as a plain unordered html list.
The simplest use for this would be an automated navigaton list
generator, but it could also be logically extended to create limited
lists of content according to rules.
Maybe the best place to start would for you to clarify what the
JavaScript in the current menu system actually does.
BTW: my responses over the next few days may be a little slow - I'll
be out of contact for most of this weekend, back Monday night.
paul b
> Since I understand the JavaScript of the menu system now I'd be happy
> to help.
>
> --
> Ferdinand Soethe
>
>
Re: The future (was Re: New skin: Coat)
Posted by Ferdinand Soethe <fe...@apache.org>.
Paul Bolger wrote:
> I think the appropriate time to do this would be immediately after the
> official dispatcher release. Anyone interested in collaborating?
Since I understand the JavaScript of the menu system now I'd be happy
to help.
--
Ferdinand Soethe
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mié, 11-01-2006 a las 23:21 +1300, Paul Bolger escribió:
>
>>>Sounds to me like Forrest should be generating an RSS feed of these news
>>>items. You could then leverage the feeder plugin for your home page
>>>headlines, whilst you would also be able to provide feeds for external
>>>sites.
>>>
>>>Since RSS is a more widely adopted standard for this kind of thing I'd
>>>recommend using creating a plugin that built the RSS feed rather than
>>>the custom navigation.
>>
>>This is getting away from my initial proposal somewhat, which was more
>>of a content indexer. Don't take that as too negative though: I'm
>>fully prepared to be convinced on this and I'm interested in being
>>part of the development process. I must admit that I'm a little hazy
>>about how RSS would work in this context.
>>
>>
>>>>what you're talking about but I'm thinking you could do something like
>>>>this:
>>>>o) Add a metadata element called "expires":
>>>><meta name="expires" value="1/11/2006"/>
>>>
>>>other meta-data, such as keywords, summary and publication date could
>>>also be used to good effect. But one at a time is a good idea ;-)
>>
>>The only problem with 'expires' is that - this is a real world
>>situation - everyone goes off on holidays and the news items all get
>>automatically killed. No news isn't good news if you have a space for
>>four items on your page! I'd prefer "the last four stories published".
>>I'm interested in how one would go about adding the extra metadata
>>element. Is it possible for the source doc to have an appended, or
>>extra, DTD with custom elements?
>
>
> The biggest problem I see is that the provide functionality is a CMS
> feature. Forrest is not a CMS it is a renderer.
Hmmmm....
I see your point. The back-end CMS would be a better place to do this.
This is another good reason to do it with RSS feeds, which could be
provided by the CMS, rather than with Forrest itself.
But then again, deciding what to publish is the role of the publishin
engine.
The lines are blurred here, I do not see a clear distinction between
where publishing ends and where management begins.
I think it's a case of "have the itch? scratch it".
Ross
Re: Manageing pres releases and news items (Re: The future (was
Re: New skin: Coat))
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 11-01-2006 a las 23:21 +1300, Paul Bolger escribió:
> > Sounds to me like Forrest should be generating an RSS feed of these news
> > items. You could then leverage the feeder plugin for your home page
> > headlines, whilst you would also be able to provide feeds for external
> > sites.
> >
> > Since RSS is a more widely adopted standard for this kind of thing I'd
> > recommend using creating a plugin that built the RSS feed rather than
> > the custom navigation.
>
> This is getting away from my initial proposal somewhat, which was more
> of a content indexer. Don't take that as too negative though: I'm
> fully prepared to be convinced on this and I'm interested in being
> part of the development process. I must admit that I'm a little hazy
> about how RSS would work in this context.
>
> > > what you're talking about but I'm thinking you could do something like
> > > this:
> > > o) Add a metadata element called "expires":
> > > <meta name="expires" value="1/11/2006"/>
> >
> > other meta-data, such as keywords, summary and publication date could
> > also be used to good effect. But one at a time is a good idea ;-)
>
> The only problem with 'expires' is that - this is a real world
> situation - everyone goes off on holidays and the news items all get
> automatically killed. No news isn't good news if you have a space for
> four items on your page! I'd prefer "the last four stories published".
> I'm interested in how one would go about adding the extra metadata
> element. Is it possible for the source doc to have an appended, or
> extra, DTD with custom elements?
The biggest problem I see is that the provide functionality is a CMS
feature. Forrest is not a CMS it is a renderer.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>RSS is a standard format fur such things. It lists content of a
>>particular type in a format that can be read by a large number of
>>clients, not just Forrest.
>
>
>>The idea would be create an RSS feed of all items, then use the feeder
>>plugin (with modifications) to return the top four items.
>
>
>
> Ok, I understand that. One point though: isn't converting the whole
> set of documents to RSS going to be a bit resource intensive?
By "all items" I meant "all news items". The amount of processing is no
greater than creating a custom navigation plugin. It's almost identical
except that I am proposing using a standard intermediate format (RSS) to
enable reuse in a broader set of use cases.
Ross
Re: Manageing pres releases and news items (Re: The future (was Re: New skin: Coat))
Posted by Paul Bolger <pb...@gmail.com>.
> RSS is a standard format fur such things. It lists content of a
> particular type in a format that can be read by a large number of
> clients, not just Forrest.
> The idea would be create an RSS feed of all items, then use the feeder
> plugin (with modifications) to return the top four items.
Ok, I understand that. One point though: isn't converting the whole
set of documents to RSS going to be a bit resource intensive?
> If someone wants the expires meta-data then they can use it within the
> RSS generation, everything is optional ;-)
Just putting in a bid for what I'd find useful :)
> Our DTD's support meta-data elements, however, we do not (yet) handle
> meta-data well within Forrest.
Sounds like a goal for the XHTML2 translation... It would be good to
be able to add elements to source documents which could be used for
output processing.
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>Sounds to me like Forrest should be generating an RSS feed of these news
>>items. You could then leverage the feeder plugin for your home page
>>headlines, whilst you would also be able to provide feeds for external
>>sites.
>>
>>Since RSS is a more widely adopted standard for this kind of thing I'd
>>recommend using creating a plugin that built the RSS feed rather than
>>the custom navigation.
>
>
> This is getting away from my initial proposal somewhat, which was more
> of a content indexer. Don't take that as too negative though: I'm
> fully prepared to be convinced on this and I'm interested in being
> part of the development process. I must admit that I'm a little hazy
> about how RSS would work in this context.
RSS is a standard format fur such things. It lists content of a
particular type in a format that can be read by a large number of
clients, not just Forrest.
>>>what you're talking about but I'm thinking you could do something like
>>>this:
>>>o) Add a metadata element called "expires":
>>><meta name="expires" value="1/11/2006"/>
>>
>>other meta-data, such as keywords, summary and publication date could
>>also be used to good effect. But one at a time is a good idea ;-)
>
>
> The only problem with 'expires' is that - this is a real world
> situation - everyone goes off on holidays and the news items all get
> automatically killed.
> No news isn't good news if you have a space for
> four items on your page! I'd prefer "the last four stories published".
So don't use it in your use case.
The idea would be create an RSS feed of all items, then use the feeder
plugin (with modifications) to return the top four items.
If someone wants the expires meta-data then they can use it within the
RSS generation, everything is optional ;-)
> I'm interested in how one would go about adding the extra metadata
> element. Is it possible for the source doc to have an appended, or
> extra, DTD with custom elements?
Our DTD's support meta-data elements, however, we do not (yet) handle
meta-data well within Forrest.
Ross
Re: Manageing pres releases and news items (Re: The future (was Re: New skin: Coat))
Posted by Paul Bolger <pb...@gmail.com>.
> Sounds to me like Forrest should be generating an RSS feed of these news
> items. You could then leverage the feeder plugin for your home page
> headlines, whilst you would also be able to provide feeds for external
> sites.
>
> Since RSS is a more widely adopted standard for this kind of thing I'd
> recommend using creating a plugin that built the RSS feed rather than
> the custom navigation.
This is getting away from my initial proposal somewhat, which was more
of a content indexer. Don't take that as too negative though: I'm
fully prepared to be convinced on this and I'm interested in being
part of the development process. I must admit that I'm a little hazy
about how RSS would work in this context.
> > what you're talking about but I'm thinking you could do something like
> > this:
> > o) Add a metadata element called "expires":
> > <meta name="expires" value="1/11/2006"/>
>
> other meta-data, such as keywords, summary and publication date could
> also be used to good effect. But one at a time is a good idea ;-)
The only problem with 'expires' is that - this is a real world
situation - everyone goes off on holidays and the news items all get
automatically killed. No news isn't good news if you have a space for
four items on your page! I'd prefer "the last four stories published".
I'm interested in how one would go about adding the extra metadata
element. Is it possible for the source doc to have an appended, or
extra, DTD with custom elements?
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
> (ross)
>
>> This would be a good compliement to the Feeder plugin - but like Thorsten
>>obsered in earlier, we are getting dangerously close to doing things that a
>>CMS system should really be doing for us. This is a very grey area - I'm not
>>sure which side of the fence I sit on yet.
>
>
> I think it's a discussion well worth having. I suspect that it would
> be better, or more likely to succeed at any rate, to concentrate on
> developing useful applications for Forrest than getting too bogged
> down with semantics. Forrest can be a slippery fish when it comes down
> to defining exactly what it does. Maybe we should be running a list of
> possible use cases in the docs and trying to gauge what users actually
> want most. Personally good html site generation is a priority, but
> maybe Forrest's forte is something a bit less mainstream.
I agree it is a discussion worth having.
First, if Forrest decides that a particular feature does not "fit" with
the scope of Forrest, there is nothing to stop an external developer
building and hosting the plugin elsewhere. The question is not whether
it can be developed, rather whether the Forrest project should undertake
to maintain it.
The problem is, that if we accept too many CMS like plugins two things
happen:
1) we end up with loads of unsupported plugins because the original
creators find themselves busy with other things
2) we divert attention away from useful development of other features,
such as integration with more complete tools for the job in hand. For
example, too much focus on CMS-like features will reduce effort on true
CMS integration
Your idea of a list of use cases for us to examine is a good one. In the
past we have discussed the possaiblity of providing different seed sites
for different use cases. Such a document would help us to identify those
seed sites.
As for defining what Forrest does, we spent a long time working on the
short description of Forrest to try and make it clear. Problem is, most
people fail to see the real purpose, they just think of Forrest as a web
site generation tool.
I see it more as a data integration and publishing tool. Where the data
comes from and the form it is published in is not a concern of Forrest.
Forrest, provides a framework for fullfilling all collation and
publishing needs.
Now, to your use case:
You want to automatically create RSS feeds of content. These feeds will
show the date that items were added and short summaries.
It has been argued that this is a CMS problem. However, given that
Forrest integrates data from multiple sources we cannot rely on the CMS
since it may not be aware of some of the sources of data and therefore
cannot include them in the feed.
My conclusion is therefore that a RSS output plugin is in the scope of
Forrest.
WDOT?
Ross
Re: Manageing pres releases and news items (Re: The future (was Re: New skin: Coat))
Posted by Paul Bolger <pb...@gmail.com>.
Hi Helena
> no original rss is used for rss output.
> only original, local xml content.
Good, That sounds interesting. I don't suppose you could add a sample
xdoc with the relevant metadata included to the Jira issue. BTW, that
site of yours looks pretty good.
> helena
>
>
(ross)
> This would be a good compliement to the Feeder plugin - but like Thorsten
> obsered in earlier, we are getting dangerously close to doing things that a
> CMS system should really be doing for us. This is a very grey area - I'm not
> sure which side of the fence I sit on yet.
I think it's a discussion well worth having. I suspect that it would
be better, or more likely to succeed at any rate, to concentrate on
developing useful applications for Forrest than getting too bogged
down with semantics. Forrest can be a slippery fish when it comes down
to defining exactly what it does. Maybe we should be running a list of
possible use cases in the docs and trying to gauge what users actually
want most. Personally good html site generation is a priority, but
maybe Forrest's forte is something a bit less mainstream.
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Helena Edelson <he...@greenjaguar.com>.
Hi
My existing content is standard xdocs/*.xml files.
The rss data is generated from my xml meta-data for each article entry
by type,
Let me know if you need me to be more explicit.
best,
helena
Paul Bolger wrote:
>Sorry Ross, my mail client shows pretty well the whole thread, and I
>forget that others don't see it that way. The conversation referred to
>Helena's RSS plugin (or whatever... means for using RSS in her site,
>covered in FOR-784) and her answer was regarding whether the method
>works for internal as well as external content. From what I understand
>Helen's method gets preexisting RSS data and organises it for display.
>This would certainly be useful, but automated RSS creation from
>Forrest internal docs format would be really useful. I really like the
>idea of using RSS as an internal indexing format, and just filtering
>the RSS to suit the use case.
>
>
>On 18/01/06, Paul Bolger <pb...@gmail.com> wrote:
>
>
>>>The rss is from existing content as well as newly-published content.
>>>
>>>
>>Can I just clarify, does the existing content have to be rss?
>>
>>regards
>>Paul Bolger
>>
>>
>>
>
>
>
>
--
Helena Edelson
GreenJaguar
www.greenjaguar.com
helena@greenjaguar.com
------------------------------------------------------------------------------
Application Service Provider | User Interface Design | Web Services
------------------------------------------------------------------------------
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Helena Edelson <he...@greenjaguar.com>.
Hi,
no original rss is used for rss output.
only original, local xml content.
sorry for any confusion.
helena
Ross Gardler wrote:
> Paul Bolger wrote:
>
>> Sorry Ross, my mail client shows pretty well the whole thread, and I
>> forget that others don't see it that way. The conversation referred to
>> Helena's RSS plugin (or whatever... means for using RSS in her site,
>> covered in FOR-784) and her answer was regarding whether the method
>> works for internal as well as external content. From what I understand
>> Helen's method gets preexisting RSS data and organises it for display.
>> This would certainly be useful, but automated RSS creation from
>> Forrest internal docs format would be really useful. I really like the
>> idea of using RSS as an internal indexing format, and just filtering
>> the RSS to suit the use case.
>
>
> OK, thanks.
>
> Yes, looking at Helena's contribution is requries the original source
> in RSS. It is pretty easy to create an RSS feed from existing content
> though. You would use the directory generator to create a list of
> files in on ore more directories and process that with XSL to create
> the RSS.
>
> For examples on how to do this see the projectInfo plugin which uses
> the directory generator to create site.xml entries.
>
> This would be a good compliement to the Feeder plugin - but like
> Thorsten obsered in earlier, we are getting dangerously close to doing
> things that a CMS system should really be doing for us. This is a very
> grey area - I'm not sure which side of the fence I sit on yet.
>
> Ross
>
>
--
Helena Edelson
GreenJaguar
www.greenjaguar.com
helena@greenjaguar.com
------------------------------------------------------------------------------
Application Service Provider | User Interface Design | Web Services
------------------------------------------------------------------------------
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
> Sorry Ross, my mail client shows pretty well the whole thread, and I
> forget that others don't see it that way. The conversation referred to
> Helena's RSS plugin (or whatever... means for using RSS in her site,
> covered in FOR-784) and her answer was regarding whether the method
> works for internal as well as external content. From what I understand
> Helen's method gets preexisting RSS data and organises it for display.
> This would certainly be useful, but automated RSS creation from
> Forrest internal docs format would be really useful. I really like the
> idea of using RSS as an internal indexing format, and just filtering
> the RSS to suit the use case.
OK, thanks.
Yes, looking at Helena's contribution is requries the original source in
RSS. It is pretty easy to create an RSS feed from existing content
though. You would use the directory generator to create a list of files
in on ore more directories and process that with XSL to create the RSS.
For examples on how to do this see the projectInfo plugin which uses the
directory generator to create site.xml entries.
This would be a good compliement to the Feeder plugin - but like
Thorsten obsered in earlier, we are getting dangerously close to doing
things that a CMS system should really be doing for us. This is a very
grey area - I'm not sure which side of the fence I sit on yet.
Ross
Re: Manageing pres releases and news items (Re: The future (was Re: New skin: Coat))
Posted by Paul Bolger <pb...@gmail.com>.
Sorry Ross, my mail client shows pretty well the whole thread, and I
forget that others don't see it that way. The conversation referred to
Helena's RSS plugin (or whatever... means for using RSS in her site,
covered in FOR-784) and her answer was regarding whether the method
works for internal as well as external content. From what I understand
Helen's method gets preexisting RSS data and organises it for display.
This would certainly be useful, but automated RSS creation from
Forrest internal docs format would be really useful. I really like the
idea of using RSS as an internal indexing format, and just filtering
the RSS to suit the use case.
On 18/01/06, Paul Bolger <pb...@gmail.com> wrote:
> > The rss is from existing content as well as newly-published content.
>
>
> Can I just clarify, does the existing content have to be rss?
>
> regards
> Paul Bolger
>
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>The rss is from existing content as well as newly-published content.
>
>
>
> Can I just clarify, does the existing content have to be rss?
I'm not sure who wrote that or what the context was. I recall there were
a couple of solutions discussed in this thread. If the above quote is
mine please provide a memory jogger for me.
Ross
Re: Manageing pres releases and news items (Re: The future (was Re: New skin: Coat))
Posted by Paul Bolger <pb...@gmail.com>.
> The rss is from existing content as well as newly-published content.
Can I just clarify, does the existing content have to be rss?
regards
Paul Bolger
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Helena Edelson <he...@greenjaguar.com>.
Ross Gardler wrote:
> Helena Edelson wrote:
>
>>
>>
>> Ross Gardler wrote:
>>
>>> Helena Edelson wrote:
>>>
>>>> I don't know if I can help but I have several content RSS feeds on
>>>> one of my forrest sites, http://summitjournal.com
>>>> it was really simple do customize.
>>>
>>>
>>>
>
> ...
>
>>>
>>> [context: creating RSS feeds from Forrest content objects]
>>>
>>> Can you explain a little about how you create these feeds?
>>>
>
> ...
>
>>
>> I set up my RSS pages rather simply by implementing 4 things:
>> 1. skin/....html/rss2document.xsl
>> 2. resources/stylesheets/feeds.xsl
>> 3. skinconf
>> 4. xmap
>
>
> So, if I understand correctly you are not creating RSS feeds from
> existing content, rather you are including RSS feeds within your site.
>
> Did you try the feeder plugin before doing this work? That plugin is a
> very simple rss input plugin.
>
> Would you like to contribute your ehancements to that plugin? Don't
> worry if you don't have the time to merge your work with the plugin
> code itself, simply open an issue and attach the feeds.xsl, details of
> any relevant skinconf.xml extensions and the relevant xmap snippets.
>
> That way we know the information is there and when someone has a
> strong enough itch they can scratch it using your code as a base.
>
> Ross
>
>
The rss is from existing content as well as newly-published content.
Have not tried feeder yet.
I'd be happy to contribute if it helps. I'll upload it later today.
Helena
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Helena Edelson wrote:
>
>
> Ross Gardler wrote:
>
>> Helena Edelson wrote:
>>
>>> I don't know if I can help but I have several content RSS feeds on
>>> one of my forrest sites, http://summitjournal.com
>>> it was really simple do customize.
>>
>>
...
>>
>> [context: creating RSS feeds from Forrest content objects]
>>
>> Can you explain a little about how you create these feeds?
>>
...
>
> I set up my RSS pages rather simply by implementing 4 things:
> 1. skin/....html/rss2document.xsl
> 2. resources/stylesheets/feeds.xsl
> 3. skinconf
> 4. xmap
So, if I understand correctly you are not creating RSS feeds from
existing content, rather you are including RSS feeds within your site.
Did you try the feeder plugin before doing this work? That plugin is a
very simple rss input plugin.
Would you like to contribute your ehancements to that plugin? Don't
worry if you don't have the time to merge your work with the plugin code
itself, simply open an issue and attach the feeds.xsl, details of any
relevant skinconf.xml extensions and the relevant xmap snippets.
That way we know the information is there and when someone has a strong
enough itch they can scratch it using your code as a base.
Ross
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Helena Edelson <he...@greenjaguar.com>.
Ross Gardler wrote:
> Helena Edelson wrote:
>
>> I don't know if I can help but I have several content RSS feeds on
>> one of my forrest sites, http://summitjournal.com
>> it was really simple do customize.
>
>
> [please do not top post, it loses context and results in far too much
> content being duplicated between mails]
>
> [context: creating RSS feeds from Forrest content objects]
>
> Can you explain a little about how you create these feeds?
>
> Ross
>
>
Sorry, that was unintentional and it was 4am.
I set up my RSS pages rather simply by implementing 4 things:
1. skin/....html/rss2document.xsl
2. resources/stylesheets/feeds.xsl
3. skinconf
4. xmap
Steps:
1. I set a few attributes I would regularly need to change in skinconf
such as:
<rss-updated>Wed, 11 Jan 2006 02:25 GMT</rss-updated> since it isn't
updated daily and I don't want the rss bots and readers hitting my site
giving me unuseful info for my logs.
2. rss2document.xsl is right from the distribution
3. feeds.xsl is the template I use to pipe everything through - all
content feeds plus content channel feeds.
1. I set up a few variables to get data for the rss header info for
accurate content searches on the rss repositories
(i.e. people looking for content on syndic8 and so forth).
2. Make skinconf data accessible to feeds.xsl
3. In sitemap, I set the pipelines for all the iterations of rss files
to be created.
Only 2 variants for each pipeline are needed:
1. Filename: such as news-feed.xml)
2. The parameter(s) mapped from <map:resource> aggregator which
holds all articles data.
4. Feeds.xsl template
// forrest stuff
// rss stuff
<rss version="2.0">
<channel>
<title/>
<link/>
<description/>
<language/>
<copyright/>
<pubDate/>
<lastBuildDate/>
<category/>
<ttl/>
<image>
<title/>
<url/>
<link/>
</image>
// now get article data from xml data files based on the parameter(s) in
xmap
<xsl:for-each select="">
<item/>
<title/>
<link/>
<guid/>
<description/>
<pubDate/>
</item>
</xsl:for-each>
</channel>
</rss>
Helena
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Helena Edelson wrote:
> I don't know if I can help but I have several content RSS feeds on one
> of my forrest sites, http://summitjournal.com
> it was really simple do customize.
[please do not top post, it loses context and results in far too much
content being duplicated between mails]
[context: creating RSS feeds from Forrest content objects]
Can you explain a little about how you create these feeds?
Ross
Re: Manageing pres releases and news items (Re: The future (was Re:
New skin: Coat))
Posted by Helena Edelson <he...@greenjaguar.com>.
I don't know if I can help but I have several content RSS feeds on one
of my forrest sites, http://summitjournal.com
it was really simple do customize.
Helena
Ross Gardler wrote:
> Tim Williams wrote:
>
>> On 1/10/06, Paul Bolger <pb...@gmail.com> wrote:
>>
>>>> Have you got the news sources in RSS? If so use the Feeder
>>>> plugin/contract. (note that contract should now be moved to the feeder
>>>> plugin since we now have that capability)
>>>
>>>
>>> No, the stories are just (hypothetically) Forrest internal document
>>> format. In most sites I work on the most frequent content additions
>>> are press releases, which can be in html, and which are then saved to
>>> a 'news' directory.
>>
>
> Sounds to me like Forrest should be generating an RSS feed of these
> news items. You could then leverage the feeder plugin for your home
> page headlines, whilst you would also be able to provide feeds for
> external sites.
>
> Since RSS is a more widely adopted standard for this kind of thing I'd
> recommend using creating a plugin that built the RSS feed rather than
> the custom navigation.
>
>>> The idea would be to get Forrest to manage the
>>> links and possibly the archiving. Archiving in this sense would
>>> consist purely of moving the link from a 'current' list to an
>>> 'archive' list.
>>
>>
>>
>> I like this idea and think it's related to what I was trying to do
>> with the blog plugin -- use metadata to drive some of forrest's pages.
>
>
> I actually have a use case for something like this - seems like we
> have momentum (although, as ever little actual time).
>
>> I haven't read this whole thread so I may in fact be *way* off of
>
>
> We should have changed the subject a couple of messages ago, you are
> most likely up to speed, this emerged from the other thread but is
> quite different.
>
>> what you're talking about but I'm thinking you could do something like
>> this:
>> o) Add a metadata element called "expires":
>> <meta name="expires" value="1/11/2006"/>
>
>
> other meta-data, such as keywords, summary and publication date could
> also be used to good effect. But one at a time is a good idea ;-)
>
>> o) Use the xpathdirectorygenerator against your news directory to see
>> if it's "recent" or not.
>>
>> When I get home and finish playing around with the photogallery
>> plugin I'll get back to that blog one to try to finish it up as a good
>> example of how to use metadata in a more powerful way in forrest -
>> it's certainly not there yet.
>
>
> Cool, hopefully Paul and I will be free to participate too.
>
> Ross
>
>
--
Helena Edelson
GreenJaguar
www.greenjaguar.com
helena@greenjaguar.com
--------------------------
Web Solutions & Services
Content Development
--------------------------
Manageing pres releases and news items (Re: The future (was Re: New
skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 1/10/06, Paul Bolger <pb...@gmail.com> wrote:
>
>>>Have you got the news sources in RSS? If so use the Feeder
>>>plugin/contract. (note that contract should now be moved to the feeder
>>>plugin since we now have that capability)
>>
>>No, the stories are just (hypothetically) Forrest internal document
>>format. In most sites I work on the most frequent content additions
>>are press releases, which can be in html, and which are then saved to
>>a 'news' directory.
Sounds to me like Forrest should be generating an RSS feed of these news
items. You could then leverage the feeder plugin for your home page
headlines, whilst you would also be able to provide feeds for external
sites.
Since RSS is a more widely adopted standard for this kind of thing I'd
recommend using creating a plugin that built the RSS feed rather than
the custom navigation.
>>The idea would be to get Forrest to manage the
>>links and possibly the archiving. Archiving in this sense would
>>consist purely of moving the link from a 'current' list to an
>>'archive' list.
>
>
> I like this idea and think it's related to what I was trying to do
> with the blog plugin -- use metadata to drive some of forrest's pages.
I actually have a use case for something like this - seems like we have
momentum (although, as ever little actual time).
> I haven't read this whole thread so I may in fact be *way* off of
We should have changed the subject a couple of messages ago, you are
most likely up to speed, this emerged from the other thread but is quite
different.
> what you're talking about but I'm thinking you could do something like
> this:
> o) Add a metadata element called "expires":
> <meta name="expires" value="1/11/2006"/>
other meta-data, such as keywords, summary and publication date could
also be used to good effect. But one at a time is a good idea ;-)
> o) Use the xpathdirectorygenerator against your news directory to see
> if it's "recent" or not.
>
> When I get home and finish playing around with the photogallery
> plugin I'll get back to that blog one to try to finish it up as a good
> example of how to use metadata in a more powerful way in forrest -
> it's certainly not there yet.
Cool, hopefully Paul and I will be free to participate too.
Ross
Re: The future (was Re: New skin: Coat)
Posted by Tim Williams <wi...@gmail.com>.
On 1/10/06, Paul Bolger <pb...@gmail.com> wrote:
> > Have you got the news sources in RSS? If so use the Feeder
> > plugin/contract. (note that contract should now be moved to the feeder
> > plugin since we now have that capability)
>
> No, the stories are just (hypothetically) Forrest internal document
> format. In most sites I work on the most frequent content additions
> are press releases, which can be in html, and which are then saved to
> a 'news' directory. The idea would be to get Forrest to manage the
> links and possibly the archiving. Archiving in this sense would
> consist purely of moving the link from a 'current' list to an
> 'archive' list.
I like this idea and think it's related to what I was trying to do
with the blog plugin -- use metadata to drive some of forrest's pages.
I haven't read this whole thread so I may in fact be *way* off of
what you're talking about but I'm thinking you could do something like
this:
o) Add a metadata element called "expires":
<meta name="expires" value="1/11/2006"/>
o) Use the xpathdirectorygenerator against your news directory to see
if it's "recent" or not.
When I get home and finish playing around with the photogallery
plugin I'll get back to that blog one to try to finish it up as a good
example of how to use metadata in a more powerful way in forrest -
it's certainly not there yet.
--tim
Re: The future (was Re: New skin: Coat)
Posted by Paul Bolger <pb...@gmail.com>.
> Have you got the news sources in RSS? If so use the Feeder
> plugin/contract. (note that contract should now be moved to the feeder
> plugin since we now have that capability)
No, the stories are just (hypothetically) Forrest internal document
format. In most sites I work on the most frequent content additions
are press releases, which can be in html, and which are then saved to
a 'news' directory. The idea would be to get Forrest to manage the
links and possibly the archiving. Archiving in this sense would
consist purely of moving the link from a 'current' list to an
'archive' list.
Re: The future (was Re: New skin: Coat)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>it is *really* easy. The best way to start is to write a custom theme.
>
>
> I'll give it a go - tried renaming contracts and couldn't get it to
> work. I'd be interested to learn more about the relationship between
> themes and contracts - I presume that contracts are somehow
> 'registered' with their parent theme. Where is this set?
They are "registered" by virtue of being found by Forrest, there is no
formal registration. Given that requesting "ls.contracts.html" gives a
list of the available contracts [1] you could find out how this list is
created:
[OT] Unfortunately, following how this is done in the code is *really*
difficult due to the amount of indirection between the locationmap and
the sitemaps. There is even indirection from the structurer sitemap to
the themer locationmap and back to the structurer sitemap (now I really
understand Tims request to avoid such indirection, I was about to write
the various snippets that result in the contracts being resolved so that
all could benefit, but it's just too complicated - we need to sort this
out). Instead I have gone for an unifmormative answer rather than an
informative explanation....
Basically if a plugin is found in one of the themer contracts
directories or the projects contracts directory it will be used when
appropriate. That is:
org.apache.forrest.plugin.output.themer/resources/themes/common/html/
org.apache.forrest.plugin.output.themer/resources/themes/pelt/html/
org.apache.forrest.plugin.output.themer/resources/themes/mycustomtheme/html/
(see recent discussion about theme plugins that will allow you to
provide them in a new type of plugin)
or...
PROEJECT_HOME/src/documentation/resources/themes/common/html/
PROEJECT_HOME/src/documentation/resources/themes/pelt/html/
PROEJECT_HOME/src/documentation/resources/themes/mycustomtheme/html/
I note that this information is not clearly expressed in [1], perhaps
you could provide a patch for that doc.
>>>- a set of
>>>contracts to produce very plain lists of links according to various
>>>criteria would be very useful.
>>
>>What do you mean with this?
>
>
> A bit of background: The sort of websites I produce use a lot of lists
> of links, and a lot of time-based publishing. A good example of this
> is the 'news' style element, which usually appears on the front page.
> This is a list of the four most recent items from a 'news' directory,
> and will usually have the title and first sentence of the story with a
> link to the whole document. From what I understand of Forrest there is
> no reason why it shouldn't be possible to have a contract which
> performs the following:
> match documents using criteria x, criteria y etc
> optionally limit the list by a number, date etc
> sort matching documents by x
> generate list of urls (with some fancy regular expressions stuff to
> make the list mean more for humans!) inside a standard html unordered
> list.
Have you got the news sources in RSS? If so use the Feeder
plugin/contract. (note that contract should now be moved to the feeder
plugin since we now have that capability)
Yes it is possible, and I would say, desireable.
> Looking towards 1.0 I think we should be looking at identifying the
> parts of Forrest which not generic and trying make them optional.
That's the intention of the plugin system and the dispatcher system.
> Another example of Forrest specific would be the 'warning', 'fixme'
> etc classes. It would be vastly preferable to be able to add custom
> classes/elements if one needed them and to keep the central document
> types as neutral as possible.
Yes, see our intended move to XHTML2.
Ross
[1]
http://forrest.apache.org/docs_0_80/howto/howto-structurer-dsl.html#firststructurer
Re: The future (was Re: New skin: Coat)
Posted by Paul Bolger <pb...@gmail.com>.
> Hmm, yes because the dispatcher is grown from skins and have to slimed
> down. The best way is to return a simple txt string. That would enhance
> the usability of the contract in different formats.
"...best way is to return a simple txt string" - could you explain
this a bit more?
> it is *really* easy. The best way to start is to write a custom theme.
I'll give it a go - tried renaming contracts and couldn't get it to
work. I'd be interested to learn more about the relationship between
themes and contracts - I presume that contracts are somehow
'registered' with their parent theme. Where is this set?
> > - a set of
> > contracts to produce very plain lists of links according to various
> > criteria would be very useful.
>
> What do you mean with this?
A bit of background: The sort of websites I produce use a lot of lists
of links, and a lot of time-based publishing. A good example of this
is the 'news' style element, which usually appears on the front page.
This is a list of the four most recent items from a 'news' directory,
and will usually have the title and first sentence of the story with a
link to the whole document. From what I understand of Forrest there is
no reason why it shouldn't be possible to have a contract which
performs the following:
match documents using criteria x, criteria y etc
optionally limit the list by a number, date etc
sort matching documents by x
generate list of urls (with some fancy regular expressions stuff to
make the list mean more for humans!) inside a standard html unordered
list.
Of course it may make more sense to have a number of contracts which
provide different variations on this. I was being a bit vague in the
previous email as I thought it would be a good start to tackle the
first part, matching, and get fancy later.
To me the current navigation scheme is has some shortcomings: they
are generated from the two config files, site.xml and tabs.xml. One
problem with this is that it's manual - there is no advantage over
maintaining an SSI include navigation file, which is the way I'm
accustomed to working, and another disadvantage in that one is limited
to two navigation elements. (On reflection I'm probably wrong here...)
I often use rather a lot of indexing/link generating schemes in a site
(nav, sub nav, local - for long documents which need their own unique
navigation - news, archived news, positions vacant, etc etc.)
Another problem I have with the current nav contracts (and, I know, I
do keep banging on about this...) is that there isn't enough control
over the output - I'm never going to use the classes which currently
get pasted onto pretty well every html element that Forrest puts out,
they are just extra code. With one exception - a mechanism to indicate
the current page - Forrest hooks provide enough control - that's what
CSS selectors are for - and the html generated at contract level
should be as plain as possible.
Looking towards 1.0 I think we should be looking at identifying the
parts of Forrest which not generic and trying make them optional.
Another example of Forrest specific would be the 'warning', 'fixme'
etc classes. It would be vastly preferable to be able to add custom
classes/elements if one needed them and to keep the central document
types as neutral as possible.
> > I think the appropriate time to do this would be immediately after the
> > official dispatcher release. Anyone interested in collaborating?
>
> Yeah, I am always up for that. ;-) ...but actually that should not be to
> hard to do. Just ask if you have problems.
>
Thanks Thorsten. I'll have another play and get back to you when I get
stuck, which will be soon :)
Re: The future (was Re: New skin: Coat)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 04-01-2006 a las 10:09 +1300, Paul Bolger escribió:
> > Actually the thing that most worries me that all the conversations and
> > complaints not have been directed to this list but to others. We never
> > had a chance to help or response.
> >
> > > The way forward, in the short term, has to be to support users willing
> > > to be *power* users. We need to provide something above and beyond other
> > > tools *out of the box*. As devs we know just how powerful Forrest is,
> > > but it seems our vision is not being seen outside the project.
> > >
> >
> > Actually do not worry too much about this, we are <1.0 and not ready for
> > a big user base. Having our vision of forrest to much outside of the
> > project is producing high expectation and lots of interested users,
> > asking questions, that we will answer and not working on 1.0.
> >
> > You pointed out our target user: *power* users, that give valuable
> > feedback how we have to enhance.
> >
> > > We need to make it as simple as possible for power users to stay up to
> > > date (see other threads). Once we have that in place we can start going
> > > out there looking for those users, I would propose putting together a
> > > demo of a (single site) site-build project and taking it to site-dev as
> > > a prototype (we have much to do before we do that though - this is a
> > > medium term vision).
> > >
> >
> Having had a chance to experiment a bit with the dispatcher I keep
> finding that the existing contracts are too Forrest, or Apache,
> specific
Hmm, yes because the dispatcher is grown from skins and have to slimed
down. The best way is to return a simple txt string. That would enhance
the usability of the contract in different formats.
> - it's no coincidence that most 'Forrest Powered' sites look
> a little bit like the Forrest site.
Yeah, because they use our skins. Since Pelt is our default skin I
imagine a lot of sites are using this skin.
> I'd like to propose (and in plain
> English this means I'd like to do it, but don't have the technical
> ability to pull it off on my own...) a set of contracts to overcome
> this.
it is *really* easy. The best way to start is to write a custom theme.
a) create a new theme (you can simply copy the pelt theme into your
local theme directory "project.resources-dir/themes" and rename it to
e.g. "peel". You need pelt* (pelt.fv + pelt/).
> New navigation contracts would be a good start: nav-main and
> nav-section are very much based on the original Forrest site (and
> nav-section relies on Javascript, a big problem for me)
b) edit/create themes/peel/html/nav-main-sub.ft to meet your needs.
BTW why do you not just use the one from common? No javascript in that
one. If you remove the nav-main-sub.ft from themes/peel you will
automatically use the one from common. ;-)
that is actually the power of themes. If you have really good common
contracts you can create themes that contains only *one* contract the
one you wish to override or add. So in the future you only have to
maintain this contract nothing more. :)
> - a set of
> contracts to produce very plain lists of links according to various
> criteria would be very useful.
What do you mean with this?
> I think the appropriate time to do this would be immediately after the
> official dispatcher release. Anyone interested in collaborating?
Yeah, I am always up for that. ;-) ...but actually that should not be to
hard to do. Just ask if you have problems.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: New contracts (Re: The future (was Re: New skin: Coat))
Posted by Paul Bolger <pb...@gmail.com>.
On 04/01/06, Ross Gardler <rg...@apache.org> wrote:
> Paul Bolger wrote:
> > Having had a chance to experiment a bit with the dispatcher I keep
> > finding that the existing contracts are too Forrest, or Apache,
> > specific - it's no coincidence that most 'Forrest Powered' sites look
> > a little bit like the Forrest site.
>
> Very true.
>
> > I'd like to propose (and in plain
> > English this means I'd like to do it, but don't have the technical
> > ability to pull it off on my own...) a set of contracts to overcome
> > this.
>
> It's easy to do, we'll help if you ask direct questions. FOr more
> general stuff the archives and docs are your friends.
>
> > New navigation contracts would be a good start: nav-main and
> > nav-section are very much based on the original Forrest site (and
> > nav-section relies on Javascript, a big problem for me) - a set of
> > contracts to produce very plain lists of links according to various
> > criteria would be very useful.
>
> [OT} the nav-section contract no longer depends on javascript. You can
> turn off the javascript stuff with a property, see the usage example in
> the contract.
>
> > I think the appropriate time to do this would be immediately after the
> > official dispatcher release. Anyone interested in collaborating?
>
> Timing - no time like the present.
> I'm interesting in collaborating by advising. I don't need any new
> contracts right now, but if you define what you want to do and ask a
> direct question about how to do it then I will do my best to answer. As
> will others.
That sounds good.
Thanks Ross, I'm about to set off on a four-day trip (away from
computers) so will pick this up when I return.
paul
New contracts (Re: The future (was Re: New skin: Coat))
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
> Having had a chance to experiment a bit with the dispatcher I keep
> finding that the existing contracts are too Forrest, or Apache,
> specific - it's no coincidence that most 'Forrest Powered' sites look
> a little bit like the Forrest site.
Very true.
> I'd like to propose (and in plain
> English this means I'd like to do it, but don't have the technical
> ability to pull it off on my own...) a set of contracts to overcome
> this.
It's easy to do, we'll help if you ask direct questions. FOr more
general stuff the archives and docs are your friends.
> New navigation contracts would be a good start: nav-main and
> nav-section are very much based on the original Forrest site (and
> nav-section relies on Javascript, a big problem for me) - a set of
> contracts to produce very plain lists of links according to various
> criteria would be very useful.
[OT} the nav-section contract no longer depends on javascript. You can
turn off the javascript stuff with a property, see the usage example in
the contract.
> I think the appropriate time to do this would be immediately after the
> official dispatcher release. Anyone interested in collaborating?
Timing - no time like the present.
I'm interesting in collaborating by advising. I don't need any new
contracts right now, but if you define what you want to do and ask a
direct question about how to do it then I will do my best to answer. As
will others.
Ross
Re: The future (was Re: New skin: Coat)
Posted by Paul Bolger <pb...@gmail.com>.
> Actually the thing that most worries me that all the conversations and
> complaints not have been directed to this list but to others. We never
> had a chance to help or response.
>
> > The way forward, in the short term, has to be to support users willing
> > to be *power* users. We need to provide something above and beyond other
> > tools *out of the box*. As devs we know just how powerful Forrest is,
> > but it seems our vision is not being seen outside the project.
> >
>
> Actually do not worry too much about this, we are <1.0 and not ready for
> a big user base. Having our vision of forrest to much outside of the
> project is producing high expectation and lots of interested users,
> asking questions, that we will answer and not working on 1.0.
>
> You pointed out our target user: *power* users, that give valuable
> feedback how we have to enhance.
>
> > We need to make it as simple as possible for power users to stay up to
> > date (see other threads). Once we have that in place we can start going
> > out there looking for those users, I would propose putting together a
> > demo of a (single site) site-build project and taking it to site-dev as
> > a prototype (we have much to do before we do that though - this is a
> > medium term vision).
> >
>
Having had a chance to experiment a bit with the dispatcher I keep
finding that the existing contracts are too Forrest, or Apache,
specific - it's no coincidence that most 'Forrest Powered' sites look
a little bit like the Forrest site. I'd like to propose (and in plain
English this means I'd like to do it, but don't have the technical
ability to pull it off on my own...) a set of contracts to overcome
this. New navigation contracts would be a good start: nav-main and
nav-section are very much based on the original Forrest site (and
nav-section relies on Javascript, a big problem for me) - a set of
contracts to produce very plain lists of links according to various
criteria would be very useful.
I think the appropriate time to do this would be immediately after the
official dispatcher release. Anyone interested in collaborating?
Re: The future (was Re: New skin: Coat)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El lun, 02-01-2006 a las 22:55 +0000, Ross Gardler escribió:
>
>>Thorsten Scherler wrote:
>>
>>>El lun, 02-01-2006 a las 06:48 +0000, Ross Gardler escribió:
>>(don't worry I'm going to help with the Lenya stuff too)
>>
>
>
> Actually I wonder whether it is possible to extend the daisy plugin to a
> generic external repository connector plugin. I mean you are "just"
> connecting to some uri and retrieve the content from there. Or do I miss
> something?
No, you are right on the mark. I have tried to design the Daisy plugin
in as generic a way as possible. We can't make a single plugin for both
CMS', there are some fundamental differences, however, I hope to extract
the common functionality into a "base" plugin that other CMS plugins can
extend (that's why I am interested in the new wiring features in Cocoon).
>>I'm also with David that we need to pick our users carefully before the
>>1.0, anyone only willing to complain and not willing to ask simple
>>questions is not a useful resource for us right now.
>>
>
>
> Actually the thing that most worries me that all the conversations and
> complaints not have been directed to this list but to others. We never
> had a chance to help or response.
:-((
Read the archives, David has been fighting against this for a long time.
I live a 13 hour flght from David, yet I am sure I have heard him sigh
in desparation at least half a dozen times in the last week.
>>We need to make it as simple as possible for power users to stay up to
>>date (see other threads). Once we have that in place we can start going
>>out there looking for those users, I would propose putting together a
>>demo of a (single site) site-build project and taking it to site-dev as
>>a prototype (we have much to do before we do that though - this is a
>>medium term vision).
>>
>
>
> Actually I see this in connection with lenya. We should try to leverage
> CMS features to lenya and "just" providing an awesome renderer.
>
> Forrest as site-build tool would be "just" a crawling renderer capable
> of connecting to multiple content repositories. The dispatcher is the
> renderer, the cli.xconf the crawling configuration.
+10000
If we can get Lenya writing to SVN, host it in a zone, and have our
forrestbot publish from there I think we will finally have doco. The ASF
have harware to support this now. The publishing end is there (we just
need a live prototype so people can *see* it - I've done this on a
private server - just need to get it working n our zone).
The authoring end is there with Daisy, but I doubt that it will never
write to an SVN back-end and so cannot provide offline authoring which
is important.
Like I said, we are so close it hurts.
Ross
Re: The future (was Re: New skin: Coat)
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 02-01-2006 a las 22:55 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El lun, 02-01-2006 a las 06:48 +0000, Ross Gardler escribió:
> >
> >>I've been wanting to create a skin for Forrest that looks like that at
> >>http://www.apache.org for some time. Mostly because the default Forrest
> >>skins are, well "old".
> >>
> >>The recent thread on the incubator list discussing Forrest as a tool has
> >>finally prompted me into action (congrats to anyone deliberately
> >>provoking us to make this happen ;-). I've built the Incubator site
> >>using it.
> >>
> >>It's not perfect, but a a very good start. Really this should be done in
> >>the dispatcher, especially since most of the work is removing stuff from
> >>pelt and changing the CSS. However, we need this now, at least as a demo
> >>of a good clean skin. Besides, it only took about an hour and a half.
> >
> >
> > Actually I am still trying to catch up all the mails around the emerging
> > need for this and a couple of other threads, so just a quick remark
> > about it.
> >
> > Actually we can use the css and do it in a dispatcher theme. We need to
> > finish up the dispatcher and release it because it solves a lot of the
> > problems that leaded us to this new skin.
>
> I agree.
>
> I'm doing a theme for it right now.
:)
> I don't want to waste time on the
> skin version, there are some problems my CSS skills won't solve easily
> so I'm starting from scratch with a theme.
I saw the jira mails.
> The purpose of the skin was
> to show that the look and feel can be changed really quickly and there
> is no need to use unreleased features.
Yeah, still actually it showed that you needed to create a whole new
skin to just adjust "trivial" design changes. I mean like you said you
needed to mainly remove features, this is what you can do in a single
structurer. ;-) ...but it is unreleased till now. ...what will hopefully
change very soon. ;-)
>
> However, looking forward rather than backward, it appears that there is
> now hardware available for the site-build tool. Forrest is not ready for
> that, but I would like to put a demo together showing how close we are.
> People do not realise that we have been making steady progress on the
> requirements outlined at [1].
>
> The next big task with respect to the site-build tool is the handling of
> multiple projects with a single command. The new properties system
> solves the easy 80% of that, we just have the hard 20% left ;-) (oh and
> to finish the locationmap integration and the dispatcher)
>
Yeah, we have many things to finish, so no worries that we failed so
closely for the site-build tool.
> > I would be happy to create a coat theme and release the dispatcher with
> > it but IMO we need to focus on the dispatcher more then to do it in
> > skins now.
>
> You focus on the dispatcher code - that's where your knowledge is most
> valuable.
>
jeje, ok. :)
> We also need you to focus on the Lenya integration when you've finished
> the dispatcher - you have enough to do already ;-)
>
Yeah, the lenya integration has highest priority for me after final cut
of the dispatcher.
> I'll ask if I have problems with the CSS.
>
no problem
> (don't worry I'm going to help with the Lenya stuff too)
>
Actually I wonder whether it is possible to extend the daisy plugin to a
generic external repository connector plugin. I mean you are "just"
connecting to some uri and retrieve the content from there. Or do I miss
something?
> > I understand what you have done with the creation of this skin and
> > really appreciate it, but now we should finish the dispatcher. BTW IMO
> > it would have been faster to do it with a structurer + css. ;-)
>
> Yes, it would have been faster, but I wanted to show it could be done
> without using unreleased features. I'm not going to polish the skin
> version. I'm agree with you that we need to keep pushing forward.
>
k, no worries like said before I understand your very good intentions.
> I'm also with David that we need to pick our users carefully before the
> 1.0, anyone only willing to complain and not willing to ask simple
> questions is not a useful resource for us right now.
>
Actually the thing that most worries me that all the conversations and
complaints not have been directed to this list but to others. We never
had a chance to help or response.
> The way forward, in the short term, has to be to support users willing
> to be *power* users. We need to provide something above and beyond other
> tools *out of the box*. As devs we know just how powerful Forrest is,
> but it seems our vision is not being seen outside the project.
>
Actually do not worry too much about this, we are <1.0 and not ready for
a big user base. Having our vision of forrest to much outside of the
project is producing high expectation and lots of interested users,
asking questions, that we will answer and not working on 1.0.
You pointed out our target user: *power* users, that give valuable
feedback how we have to enhance.
> We need to make it as simple as possible for power users to stay up to
> date (see other threads). Once we have that in place we can start going
> out there looking for those users, I would propose putting together a
> demo of a (single site) site-build project and taking it to site-dev as
> a prototype (we have much to do before we do that though - this is a
> medium term vision).
>
Actually I see this in connection with lenya. We should try to leverage
CMS features to lenya and "just" providing an awesome renderer.
Forrest as site-build tool would be "just" a crawling renderer capable
of connecting to multiple content repositories. The dispatcher is the
renderer, the cli.xconf the crawling configuration.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
The future (was Re: New skin: Coat)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El lun, 02-01-2006 a las 06:48 +0000, Ross Gardler escribió:
>
>>I've been wanting to create a skin for Forrest that looks like that at
>>http://www.apache.org for some time. Mostly because the default Forrest
>>skins are, well "old".
>>
>>The recent thread on the incubator list discussing Forrest as a tool has
>>finally prompted me into action (congrats to anyone deliberately
>>provoking us to make this happen ;-). I've built the Incubator site
>>using it.
>>
>>It's not perfect, but a a very good start. Really this should be done in
>>the dispatcher, especially since most of the work is removing stuff from
>>pelt and changing the CSS. However, we need this now, at least as a demo
>>of a good clean skin. Besides, it only took about an hour and a half.
>
>
> Actually I am still trying to catch up all the mails around the emerging
> need for this and a couple of other threads, so just a quick remark
> about it.
>
> Actually we can use the css and do it in a dispatcher theme. We need to
> finish up the dispatcher and release it because it solves a lot of the
> problems that leaded us to this new skin.
I agree.
I'm doing a theme for it right now. I don't want to waste time on the
skin version, there are some problems my CSS skills won't solve easily
so I'm starting from scratch with a theme. The purpose of the skin was
to show that the look and feel can be changed really quickly and there
is no need to use unreleased features.
However, looking forward rather than backward, it appears that there is
now hardware available for the site-build tool. Forrest is not ready for
that, but I would like to put a demo together showing how close we are.
People do not realise that we have been making steady progress on the
requirements outlined at [1].
The next big task with respect to the site-build tool is the handling of
multiple projects with a single command. The new properties system
solves the easy 80% of that, we just have the hard 20% left ;-) (oh and
to finish the locationmap integration and the dispatcher)
> I would be happy to create a coat theme and release the dispatcher with
> it but IMO we need to focus on the dispatcher more then to do it in
> skins now.
You focus on the dispatcher code - that's where your knowledge is most
valuable.
We also need you to focus on the Lenya integration when you've finished
the dispatcher - you have enough to do already ;-)
I'll ask if I have problems with the CSS.
(don't worry I'm going to help with the Lenya stuff too)
> I understand what you have done with the creation of this skin and
> really appreciate it, but now we should finish the dispatcher. BTW IMO
> it would have been faster to do it with a structurer + css. ;-)
Yes, it would have been faster, but I wanted to show it could be done
without using unreleased features. I'm not going to polish the skin
version. I'm agree with you that we need to keep pushing forward.
I'm also with David that we need to pick our users carefully before the
1.0, anyone only willing to complain and not willing to ask simple
questions is not a useful resource for us right now.
The way forward, in the short term, has to be to support users willing
to be *power* users. We need to provide something above and beyond other
tools *out of the box*. As devs we know just how powerful Forrest is,
but it seems our vision is not being seen outside the project.
We need to make it as simple as possible for power users to stay up to
date (see other threads). Once we have that in place we can start going
out there looking for those users, I would propose putting together a
demo of a (single site) site-build project and taking it to site-dev as
a prototype (we have much to do before we do that though - this is a
medium term vision).
Ross
Re: New skin: Coat
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 02-01-2006 a las 06:48 +0000, Ross Gardler escribió:
> I've been wanting to create a skin for Forrest that looks like that at
> http://www.apache.org for some time. Mostly because the default Forrest
> skins are, well "old".
>
> The recent thread on the incubator list discussing Forrest as a tool has
> finally prompted me into action (congrats to anyone deliberately
> provoking us to make this happen ;-). I've built the Incubator site
> using it.
>
> It's not perfect, but a a very good start. Really this should be done in
> the dispatcher, especially since most of the work is removing stuff from
> pelt and changing the CSS. However, we need this now, at least as a demo
> of a good clean skin. Besides, it only took about an hour and a half.
Actually I am still trying to catch up all the mails around the emerging
need for this and a couple of other threads, so just a quick remark
about it.
Actually we can use the css and do it in a dispatcher theme. We need to
finish up the dispatcher and release it because it solves a lot of the
problems that leaded us to this new skin.
I would be happy to create a coat theme and release the dispatcher with
it but IMO we need to focus on the dispatcher more then to do it in
skins now.
I understand what you have done with the creation of this skin and
really appreciate it, but now we should finish the dispatcher. BTW IMO
it would have been faster to do it with a structurer + css. ;-)
>
> You can view the prototype skin at:
> http://people.apache.org/~rgardler/testingGround/coat/
>
> Ross
>
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)