forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Lenya may start using Forrest Plugins
Date Thu, 02 Dec 2004 11:59:07 GMT
El mar, 30-11-2004 a las 18:16, Ross Gardler escribió:
> Antonio Gallardo wrote:
> > 2-Lenya is the "content manager". On the other hand, Forrest can be viewed
> > as a content generator.
> I see it differently, Forrest is a content publisher, it does not 
> generate the content only a representation of the content.

That is quite tricky here. Forrest is both a content and presentation
framework. Forrest is not only publishing content but also is able to
work with different input formats.

Forrest provids tools to create and present content. Forrest is not
providing tools to manage content. This can be done by e.g. lenya cms.

That makes 
lenya = content manager
forrest = content creator & representation

> > The content generated by Forrest must be managed
> > by Lenya.
> For me Lenya is a tool for content generation (driven by the user).
> Lenya = excellent content managment
> Forrest = excellent publishing engine
> Lenya + Forrest = Killer App

That is a clear cut. I really would like to see that in practise, but
yourself have e.g. started a content generation plugin (HtmlArea).

IMO everything regarding the Mgt. (versioning, workflow, rights, ...)
should be done by lenya the rest by forrest. 

> > In that way, we need to "attach" Forrest to Lenya and no the
> > oposite.
> This is just semantics, it is best for us to steer away from such 
> terminology as it will only generate (probably unspoken) arguments about 
> which is the most important part. Lenya and Forrest both do vital and 
> different jobs.

Yeah, I agree, but still we have to find a way to unit them. IMO Lenya
should support forrest plugins and capsulate all existing functionality
into plugins. The only problem is who is going to do that and how can we
do it.

> > That means we need to develop some tools that Lenya will use to
> > "know how" call the tools and Forrest need to provide a support for this
> > tools called by Lenya.
> Forrest is driven, in its entirety, from URI requests. There is no need 
> for Forrest to provide any additional support (pending further 
> experimentation of course).

True, but Lenya as well is URI request based. That makes them two
different controller for one uri. We need to define how the interaction
between the two has to work. e.g. Lenya has authoring/live/admin

> > 3-Forrest need to be able to generate only a desired document. Lenya will
> > "tell" Forrest wich one by running the forrest tools.
> It already does, just request the document you want (for example 
> http://localhost:8888/mydoc.pdf or http://localhost:8888/mydoc.html)

? in lenya or in forrest? 

The other thing is that I would like *one* distribution and not two or
three seperated (lenya *and* cocoon *and* forrest)

> > 4-From Lenya can be posible to call Forrest in the same way as we call use
> > case. Here Flowscript can play an important role.
> (I don't know what you mean by "call use case", but in responding to the 
> flowscript comment I say - Too complicated, just make a request to a URI 
> at the appropriate place in a controlling sitemap.

The use case is based on lenya. We are speaking in use cases.

> > 5-An interesting point to be solved is how to merge the Lenya "sitetree"
> > with Forrest site.xml and tabs.xml. 
> Write a Forrest plugin to generate site.xml and tabs.xml from sitetree 
> (see IMSManifest plugin as an example, this creates site.xml and 
> tabs.xml from an IMS Manifest file).

or define a standard that can be used by both projects. ;-)

> > Another posible solution is a
> > synchronization of all this files or perhaps we can "forget about the tabs
> > and site in the beggining and let lenya manage it. I am not sure if this
> > will be more easy or complicated. I am also thinking that another
> > posibility to include in this point the "linkmap.html" that forrest
> > currently generate.
> It seems to me that in all of your points you are thinking of Forrest 
> running in a static mode, switch your thinking to Forrest running in a 
> dynamic mode and everything becomes much easier (interestingly this is 
> where you started by saying Forrest and Lenya can run in the same Cocoon 
> instance).

Yeah, Ross is right, but that is where everthing starts to be
complicated. ;-)

> >                                 -- 0 --
> > 
> > The other posible solution is import into Lenya some forrest plugins and
> > similar as above let Lenya manage everything.
> This is my thinking entirely. Unfortunately I do not understand Lenya 
> enough yet to fully understand how easy/difficult this would be. I keep 
> sitting down trying to do something with Lenya and then get distracted. 
> Soon though...


I would like to find a paying project to do so. I mean playing around
with plugins and make them work in lenya and forrest, but ATM my spare
time is more then limited. :( Maybe next week where we have some
holydays here in Spain.

> >                                 -- 0 --
> > 
> > We need to start with a low profile if we want to make both work together.
> > ;-)
> > 
> > WDYT?
> I agree that a low profile is required until we actualy have something 
> working. The more I look at the way Lenya works the more difficult it 
> seems, but I am sure I will "get it" soon. So where you say "both work 
> together" there are at least three of us ;-)

Yeah, IMO it should be *easy* to integrate them because both are based
on cocoon and in a dream world we just have to rewrite some matches. 

Maybe we can meet one day online via IRC with lenya and forrest devs
that are willing to help and brainstorm and start a branch with the
first steps.


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message