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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to