Hi Roger, Jeff, Steve,
Roger Ineichen wrote:
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?
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
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
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')
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
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
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?
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)
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?
Zope3-dev mailing list