Re: [Zope3-dev] Brainstorming about browser pages
On 2/23/06, Peter Simmons [EMAIL PROTECTED] wrote: of was one of the above people wanted to install a new component to add some functionality to their site. e.g. add a shopping cart/checkout component . I think it would be great if the site administrator could add this component to their site without having to contact a developer. Adding components does not require ZCML editing. Developing the components do require it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
Been busy but caught up now, thanks for taking this further (and everyone else I will get to the end soon). In an earlier email I mentioned tools for making doing ZCML easier for not technical types e.g. a site administrator that was mainly a content creator (we have a lot of these as clients). the Use case I was thinking of was one of the above people wanted to install a new component to add some functionality to their site. e.g. add a shopping cart/checkout component . I think it would be great if the site administrator could add this component to their site without having to contact a developer. After all the component isn't changing and its a component they just work right. The type of tool I was meaning could be something like a TTW way to do this, or some kind of desktop application. It has some specific use cases like add this component, customise this particular template to be one named XYZ instead of ABC. The site administrator doesn't need to know ZCML to do this but understand the concept. This tool knows how to do all things in ZCML but nothing in python as python is the developers domain. We therefore need to make sure that everything a site admin might want to do is possible in ZCML. Anyway it might not be a realistic idea but the use case is something that really will happen. Someone also said: For example, has anyone had people, who don't know or can't handle Python AT ALL, hook up page templates? We have this all the time in the plone sites we are currently doing so I imagine it will continue as we move to zope 3 way of doing things. I guess there are other ways for the designers to change the template that gets used by a particular piece of content (e.g. just change the contents of the template) but in reality they do find going into portal_types and changing the template on an action useful. Am I understanding correctly that the way you do that type of thing in zope 3 is via the ZCML at the moment? Cheers, Pete Lennart Regebro wrote: On 2/19/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Ah, ok. Well, I'm not 100% sure myself, but I would tend to say we should define things in Python first and then register it (Jim seems to think so too). I agree. I just see naming it as a part of the registration. You can change the name withouth changing the implementation. Not always, but most of the time the name of a page is completely independent from everything else except the menu item definition. For example, has anyone had people, who don't know or can't handle Python AT ALL, hook up page templates? Nope. Although I would definitely like easy overrides. But then again, I could do that by using the class that already is there and just override the something.html template, I guess. So, all in all, the boiler-plate isn't useless. It's just declarative, and I don't think it's overly wordy. Right. As with much, is a matter of where to draw lines, maybe thats the right place to draw it As a sidenote on the MVC discussion: I have discussed MVC with a friend an how it maps onto Zope3, and I have looked more closely as MVC lately, and to be honest, I think it's bunk and can be happily ignored, at least when it comes to normal HTML/HTTP stuff (maybe, just maybe, it can have applications for Ajax. Maybe). But if you should map it into Zope3, then I'd say that the view is the method you call that returns HTML, and the controller is the update method. It's mainly bunk becase you have to call the controller method for every request to see if anything happened... And although I think MVC is bunk, I'd like a better way of calling the update method than tal:define=dummy view/update or making small python wrapper methods for every template. Any ideas? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/pete-lists%40bcmpweb.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
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 classfoofoo/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
RE: [Zope3-dev] Brainstorming about browser pages
Hi Jeff
-Original Message-
From: Jeff Shell [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 18, 2006 8:05 PM
To: [EMAIL PROTECTED]
Cc: Steve Alexander; [EMAIL PROTECTED]
Subject: Re: [Zope3-dev] Brainstorming about browser pages
On 2/18/06, Roger Ineichen [EMAIL PROTECTED] wrote:
Hi Steve
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 classfoofoo/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)
I have 3 way multi adapters (context, request, parent view - but not
content providers) that exist purely for formatting. I kept having to
display the same core set of information for an Article - format a
date, turn a user id into a printable name, list tags. There were some
situations where one of those things needed to be formatted
differently: in a search results view, the matching 'tags' needed to
be highlighted. In other views, the 'tags' needed to be links to find
other Articles with that tag. So I made a browser view type object
just for this. Another view (the view listing the articles) is what
calls it and renders the formatted bits that it wants. The adapter is
queried like getMultiAdapter((article, self.request, self),
IFormattedArticleRecord), with ``self`` referring to a browser view.
I break things out like this a lot. I also don't use page templates
very much in these smaller views, but instead use an internal HTML
generation tool with ideas liberally borrowed from Nevow's stan, and
an html helper class to provide a common API for useful common
things (helper is an adapter for a request).
html = cmsapi.htmlHelperFor(self.request)
T = fdlib.tags.builder(indent=2, separator='\n')
outer = T.ul(class_='articles')
for article in self.context.values():
formatted = zapi.getMultiAdapter(
(article, self.request, self), IFormattedArticleRecord)
outer T.li(id='art_%s' % zapi.getName(article))[
html.linkTextTo(formatted.title, html.url(article)),
html.linkTextTo(
'[Delete]', html.viewURL(article, 'delete'),
post=True,
confirm=Delete article %s? %
formatted.title, class_='button
Re: [Zope3-dev] Brainstorming about browser pages
Great page. Heres the first thing I don't like: Registering it would probably work like this:: view You would register them using a ``browser:pages`` call: It is not immediately obvious to thew Zope3 newbie what the difference between a page and a view is and why we would need to differentiate between them. So I think we shouldn't use both view and page statements, but probably only have page and pages statements. Second thing: name=index.html vs @page(u'update.html') I think that unless we can move all naming into python (and I'm not sure we can) we shouldn't have any naming in Python. Consistency is the enemy of confusion! :-) Third thing: What if someone wants to customize this view by changing the template but not the helper method? You either have to subclass this view class and add a custom __call__ to your subclass, or you use *named templates* from zope.formlib: Nh. I don't like this, but I can't tell you why. Maybe just because it's too complicated. Same goes with your usecase 1. I actually don't want to create a boilerplate class just to hold page templates. And sure, if we could get rid of the automated class creation in Usecase 3b, then I'd might opt for getting rid of this class creation too, but now I just don't see why. On the other hand, in most cases it means I'll create one view class per object and tuck a lot of templates on it, but still, it doesn't feel quite right... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
* I feel that there are many usecases for multiple pages from one view class which is why I've tried to come up with a solution that has almost no magic (mind the almost). Does anyone have a better solution without magic? It's very clean and concise and relates directly to the url. I think you'll find this very appealing to the CherryPy/TurboGears crowd. usecase 1. You have a template, you simply want to register it for an interface or class. IMO every template should have a view class. I take that back. - every browser page should be a view class with an optional template. I've only built a few simple sites with Z3, but 99% of my browser pages require additional logic, especially since the prevailing opinion is that you keep all logic and processing out of the template. (see tal:defines considered harmful thread) I think the template should be considered auxillary, not the view class. ZPT isn't the only template option. As Z3 opens up, developers are going to demand more templating choices like Kid, Cheetah, Meld3, etc... Kevin Smith -- View this message in context: http://www.nabble.com/Brainstorming-about-browser-pages-t1139623.html#a2994644 Sent from the Zope3 - dev forum at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
On Fri, Feb 17, 2006 at 10:21:41AM -0800, ksmith99 wrote: I think the template should be considered auxillary, not the view class. That's how I've been thinking lately. The view class is_a view and uses_a template. ZPT isn't the only template option. As Z3 opens up, developers are going to demand more templating choices like Kid, Cheetah, Meld3, etc... ... clearsilver, stringtemplate, lxml.etree.XSLT... -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
This is another infamously long post of mine. I'll summarize my
thoughts on the brainstorming here, with details below::
Summary / Quick Thoughts
I'm not fond of browser:page. I can't wait to revisit and remove a
few uses of browser:pages that I'm still supporting because it's
proven to be very unwieldy. I find browser:view to be very useful in
its current form. I would like to see something that made exposing
view attributes as URL traversable elements as easy (or easier) than
formlib actions. I'd like to see, perhaps, a 'pagelib' that does this.
Or maybe just a little bit more work in 'zope.formlib.page' to promote
the 'update/render' style (which all of the page.Page based classes in
formlib.form use anyways), with some equally usable base classes that
made writing a template-only view a two line affair, while allowing
that view to grow in capability by adding / providing more methods::
class PageView(zope.formlib.page.Page):
def update(self):
Subclasses may use this to respond to requests and get items
ready for rendering
pass
def render(self):
raise NotImplementedError(Subclass should provide render)
def __call__(self):
self.update()
return self.render()
class TemplatedPageView(PageView):
template = ViewPageTemplateFile('empty.pt')
def render(self):
return self.template()
Also see below for thoughts on exposing multiple attributes as
traversable named 'sub-pages'.
Actual Response / Very Long Thoughts
On 2/17/06, Lennart Regebro [EMAIL PROTECTED] wrote:
Great page. Heres the first thing I don't like:
Registering it would probably work like this::
view
You would register them using a ``browser:pages`` call:
It is not immediately obvious to thew Zope3 newbie what the difference
between a page and a view is and why we would need to
differentiate between them. So I think we shouldn't use both view and
page statements, but probably only have page and pages statements.
I disagree, but it's a matter of semantics. Just like 'view' is a
matter of semantics when it comes down to it.
In the last two applications I've worked on in Zope 3, I haven't
really thought about things in terms of pages. I'm using a lot of
AJAX. I'm using viewlets and content providers, and often also just
using views on views. I have a view for managing people based objects
in a container. There are three kinds of objects that can be in that
container - a Group, a Passenger, and a Crew Member. They have slight
variations in what information they need to present. So the view
object that lists these things for management then looks up another
view (by name) to render each of the three lists. Each of those lists,
in turn, look up a very small view object for how to display the
individual content items. Each of these items has actions (like edit
or delete) that can be rendered for them, and the edit action does
in-place editing using AJAX.
In a traditional page mentality, I would have just lumped all of
this together in one template and arm wrestled my way through it. But
these days, I break everything into separate components. And it
actually makes my life easier.
What makes a lot of this work is browser:view. One of the main
reasons why is because browser:view allows me to specify a
'provides' value, so I can make views for views. Why not viewlets for
this? Because I need to traverse to them by URL.
The other thing I like about browser:view over browser:page is
that I always know what it's going to call: __call__. I've also gotten
into the habit of doing the update/render pattern. Now writing new
views and having them work as full pages, viewlets (or viewlet like),
or small chunks of HTML to be loaded in by Javascript, it's all
uniform in how I approach writing it. Sometimes a view might be as
simple as this::
class FooDisplay(BrowserView):
template = ViewPageTemplateFile('foodisplay.pt')
def update(self):
pass
def render(self):
return self.template()
def __call__(self):
self.update()
return self.render()
Yeah, that might look like a lot of work for a simple 'page'. But if
you put update, render, and __call__ into a base class just like this,
and you have a very easy to use View that is easy to extend when it
starts needing any sort of sophisticated logic. The above code would
also work in a content provider / viewlet manager, or in any view
situation that used sub-views so that all update() calls happened in
one pass, and all render() calls happened separately, yet still in a
composed manner.
My applications have had terrifically increased sophistication since
adopting this pattern. Putting aside 'page' as referred to by
'browser:page' for a moment, I just want to say that I've found
terrific freedom away from 'page' oriented thinking.
Second thing:
Re: [Zope3-dev] Brainstorming about browser pages
On 2/17/06, ksmith99 [EMAIL PROTECTED] wrote: I've only built a few simple sites with Z3, but 99% of my browser pages require additional logic, especially since the prevailing opinion is that you keep all logic and processing out of the template. (see tal:defines considered harmful thread) You are right. I withdraw my previous objection about boilerplate (almost wrote broilerplate, haha) classes, because it's not gonna happen often enough to care about. Now if we could get rid of the generated classes completely... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
