[Zope3-dev] Brainstorming about browser pages

[Peter Simmons]

Hi Roger, Jeff, Steve,

Roger Ineichen wrote:

>>>>the advantage of all this is that you need to look in just
>>>>one place to
>>>>understand a view class.  You don't need to look in both 
>>>>        
>>>>
>>the ZCML and
>>    
>>
>>>>the Python code, just the Python code.  The ZCML becomes 
>>>>        
>>>>
>>simpler, and
>>    
>>
>>>>more focused on glueing pieces of Python code together, 
>>>>        
>>>>
>>and less about
>>    
>>
>>>>what is to be displayed at what URLs.
>>>>        
>>>>
>>>Let my say somthing about that.
>>>
>>>I like it and I think it's a good way for simplifie view 
>>>      
>>>
>>registration
>>    
>>
>>>for a well defined project but not a fremawork where has to offer
>>>a more open API for views.
>>>      
>>>
>>>Why not useable in frameworks;
>>>because this means you have to use PageTemplates for such a API.
>>>But Im OK with this as long we don't propagate this as a reusable
>>>concept for the zope3 core or 3rd party applications.
>>>
>>>I like it more to see real Pyhton view API's where can be used
>>>with different templating systems in the future.
>>>      
>>>
>>I don't understand what you mean by this. At its most basic, a 'view'
>>in Zope 3 is just a multi adapter. It takes a context object (any
>>object) and a browser request and provides... Well, whatever it wants
>>to provide. Not all views are named. Not all views have page
>>templates. See Absolute URL, for example.
>>
>>Beyond that, what kind of "open API" do you need? You can have as open
>>of an API as you want.
>>    
>>
>
>
>Don't take my comments as the only correct one. This are just
>comments focusing on framework or reusable package development.
>My comments doesn't allways fit for simply straight forward 
>product development. (I don't mean quick an dirty here!)
>
>Perhaps my focus was not clearly described. I was thinking about
>views for products like a bugracker where other will apply their
>layout. In such products I like to have a open view API as possible.
>And I don't like to get HTML and CSS from the product if I have to
>customize and apply another layout. This is only possible if you 
>offer view classes not including any PageTemplate mixin.
>
>Some bad samples are for this use case:
>
>template = ViewPageTemplateFile('foo.pt')
>
>or 
>
>return "<div class"foo">foo</div>
>
>If a product like a bugtracker contains such a views. I have to 
>replace them and can't use the (view) component within a new 
>template.
>
>zope.formlib offers a cool way the get rid of hardcoded 
>ViewPageTemplateFile(), they offer a NamedTemplate which can be
>registred for skins and make the view - template relation 
>customizable.
>
>I guess my concerns about views an a open API was more going in 
>a direction like:
>
>"View - Template/Skinning - Relation"
>
>I think projects following a target like Steve describes with 
>launchpad or you describing below, will not need such a decoupeling
>of views and templates. But I think generic frameworks where users
>like to apply their layout will need it.
>
>Can you agree on this?
>
>note:
>if I use the word "view" most time I mean a python view class
>inherited from formlib.xy or BrowserView etc. (perhaps this is confusing)
>
>  
>
So is the difference between whether you are developing a bepoke one off 
(or maybe 2 off) solution vs something that is delibrately going to be 
used many times and need the look to be cusomised? In other words, do 
you need to be able to redo the templates from scratch or is it ok if 
you can't change everything?

Jeff/Steve, for your (each of them) way of doing things, do you imagine 
that each small piece of HTML is not able to be changed, but that you 
can wire the pieces together differently? Could you provide an example 
of doing this?

Cheers,
Pete