forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [Proposal] No new features into skins (was Re: [jira] Closed: (FOR-320) )
Date Wed, 13 Jul 2005 16:20:27 GMT
On Wed, 2005-07-13 at 10:48 +0200, Cyriaque Dupoirieux wrote:
> >>I will soon be on this improvment, but I don't understand what is the 
> >>impact of the project.skin property now that templates directly generate 
> >>XHTML.
> >>Thorsten, how do you imagine to be multi-skins vith views ?
> >>    
> >>
> >
> >For now we can use a new forrest.properties property for that. 
> >
> >I added in http://svn.apache.org/viewcvs?rev=215900&view=rev 
> >#views
> >project.view-defaultView=default.fv
> >
> >Now you can add to you project specific forrest.properties
> >project.view-defaultView=pelt.fv
> >  
> >
> Ok, and where do I put my pelt.fv ?
> I tried in :
> 
>     * forrest/build/plugins/org.apache.forrest.plugin.internal.view/resources/views,

That is not activated yet it will be (hopefully) tonight. ;-)

>     * project/src/documentation/conf

that got obsolete with the new fallback mechanism.

> 
> it is not taken into account...
> 
> It is only taken into account in 
> project/src/documentation/content/xdocs, but I would like to have the 
> same behaviour of inheritance as for default.fv :
> 
>     * Search for $path/myFile.fv
>     * If not found, try to take this -
>       project/src/documentation/conf/pelt.fv

I changed that with URL:
http://svn.apache.org/viewcvs?rev=209151&view=rev
Log:
Activated per dir view fallbacks. That means we match now
file-specific->(sub-)dir-specific->plugin specific views. This change
makes the conf/default.fv view obsolete, because we now expecting it in
xdocs/default.fv.

What I did with URL: http://svn.apache.org/viewcvs?rev=215900&view=rev
Log:
Activated project specific naming for the fallback view. In
forrest.properties we can now add project.view-defaultView and rename
default.fv to the way we want.

That means if you add:
project.view-defaultView=pelt.fv

and then the last fallback (former: project/src/documentation/conf/) in
the xdocs/pelt.fv will match. ...but each dir can have a pelt.fv
($project.view-defaultView) to override the default one.

>     * And - at last - if not found, take this -
>       forrest/build/plugins/org.apache.forrest.plugin.internal.view/resources/views/pelt.fv
> 

That is not yet activated but I will do that asap.

For now please use "project.view-defaultView=pelt.fv".

HTH

salu2

> Regards,
> Cyriaque,
> 
> >...and then follow
> >http://forrest.apache.org/docs_0_80/howto/howto-view-dsl.html
> >
> >to develop pelt based on views.
> >
> >Then you will end up with 1. css-file and 1. pelt.fv. 
> >
> >We will then add it to the view and we can choose 2 different skins
> >(default and pelt).
> >
> >  
> >
> >>(That is how do we manage templates, how do we manage fv files
> >>    Maybe use of different directories to store templates ?
> >>    Maybe default.skinname.fv files ?
> >>)
> >>    
> >>
> >
> >If we come to the point where we have views in the core and "view
> >plugins" that will be nearly the same. With a small extension that the
> >user can then as well define which views.xhtml plugin (s)he wants. 
> >
> >Like
> >project.views.xhtml.plugin=org.apache.forrest.plugin.output.viewHelper.xhtml
> >
> >Only that we need to move views into the core to activate that.
> >
> >Anyway if you can provide the css and view for pelt that would be more
> >then great.
> >
> >:)
> >
> >salu2
> >
> >  
> >
> >>Regards,
> >>Cyriaque,
> >>
> >>    
> >>
> >>>>You are as well admin and can reopen the issue (read on before you do).
> >>>>        
> >>>>
> >>>Yes I know. But I don't want to go stamping on what you already did 
> >>>without understanding your reasoning, you never know I might agree 
> >>>with you when you explain it to me ;-)
> >>>
> >>>      
> >>>
> >>>>Adding *new features* to skins *do not* help to make views ready to
> >>>>replace skins. Did you thought about that? 
> >>>>        
> >>>>
> >>>I agree that spending the time adding new features is not a good 
> >>>thing. However this patch already exists. as I said in my mail I agree 
> >>>that it would need to be made configurable, I'm not sure anyone will 
> >>>bother with that, I know I won't). Like I said in my original mail, 
> >>>all I am suggesting is leaving it open so that if a user wants this 
> >>>feature we can point them at the patch, or better still they will find 
> >>>it without asking questions on the lists. If the issue is closed they 
> >>>are unlikely to find it.
> >>>
> >>>      
> >>>
> >>>>...and we *do not* need pelt in views, that is not true. Why do you mean
> >>>>that?
> >>>>        
> >>>>
> >>>If you want people to adopt views I strongly recommend that we have a 
> >>>view that looks the same as pelt. Look at the number of sites on our 
> >>>example sites that use it. Most of those sites will will not switch to 
> >>>views unless at the point of switching their site looks the same as it 
> >>>does not. Then some will start playing with views and customising 
> >>>their sites look and feel because they will discover how easy it is.
> >>>
> >>>Those who are not using pelt are, in most cases, using a customised 
> >>>version of it. If you provide a view that looks like pelt it will be 
> >>>much easier for them to recreate their own site in views. Therefore, 
> >>>they are more likely to migrate to views.
> >>>
> >>>If you do not provide this migration route most existing users will 
> >>>stick with the deprecated skin for quite some time. There is no 
> >>>motivation to move from it since they are perfectly happy with what 
> >>>they have. The fact that it is cool, whizz bang technology and really 
> >>>easy to customise is irrelevant if they are happy with what they have.
> >>>
> >>>If we want to bring our existing user base to views we have to make it 
> >>>very easy for them. This means, in my opinion, that we need a view 
> >>>that looks exactly like pelt.
> >>>
> >>>      
> >>>
> >>>>Anyway I am -1 to reopen this issue and apply it to skins because that
> >>>>means we have to add yet another property to the skinconf,...
> >>>>        
> >>>>
> >>>I said reopen, not necessarily apply it, I agree with David that it 
> >>>would need to be configurable before we applied it and that involves 
> >>>spending time on it, which I agree is not a good thing, our dev time 
> >>>should go into views. However, the fact that we are deprecating the 
> >>>skin does not mean we should put contributions in a place where they 
> >>>will not be seen by existing users.
> >>>
> >>>Ross
> >>>
> >>>
> >>>      
> >>>
-- 
thorsten

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


Mime
View raw message