[Zope3-Users] Zope 3 and menus
Hi I've got a problem with menus. I'd like to define a global menu, and then add some options to it depending on actual context (view registered for specific interface). The problem is that when I define global menu element link like: action="/index.html" it generates url which omits my folder structure which shold be: root/my_site/index.html and creates: root/index.html. On the other side when i use: action="index.html" the url which is created is always relative. I'd like to be able to define my_site (which is in fact a Site object) to be root for actions. What is the correct solution for that? Should I edit global urls before displaying them (add my_site part)? Look at third code snippet below - it generates urls so I can easly change some strings. Is this a proper solution? My code: Menu definition: Global menu action (snippet from worldcookery.com code): Context dependent action: I display menu using viewlet with template (iirc code from worldcookery book): -- Jakub Wisniowski ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Crash
Paul Winkler wrote: Pound might also be a reasonable choice here. (Haven't tried it myself.) But yes, you want *something* in front of Zope. When I last encountered a project using pound, pound was the source of no-end of hair pulling and frustration. Now that projects uses Apache, Squid and LVS... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope 3 and menus
Hi there,
I override BrowserMenu from zope.app.publisher.browser.menu and add
a entry 'abs_action' to the resulting dictionary.
Something like:
class MyBrowserMenu(BrowserMenu):
def modify(self, menu, request):
siteurl = absoluteURL(hooks.getSite(), request)
for item in menu:
item['abs_action'] = siteurl + '/' + item['action']
submenu = item.get('submenu', None)
if submenu is not None:
self.modify(submenu, request)
def getMenuItems(self, obj, request):
menu = super(MyBrowserMenu, self).getMenuItems(obj, request)
self.modify(menu, request)
return menu
Cheers
-Tom
eXt wrote:
Hi
I've got a problem with menus. I'd like to define a global menu, and then add
some options to it depending on actual context (view registered for specific
interface). The problem is that when I define global menu element link like:
action="/index.html" it generates url which omits my folder structure which
shold be: root/my_site/index.html and creates: root/index.html. On the other
side when i use: action="index.html" the url which is created is always
relative. I'd like to be able to define my_site (which is in fact a Site
object) to be root for actions.
What is the correct solution for that? Should I edit global urls before
displaying them (add my_site part)? Look at third code snippet below - it
generates urls so I can easly change some strings. Is this a proper solution?
My code:
Menu definition:
Global menu action (snippet from worldcookery.com code):
Context dependent action:
I display menu using viewlet with template (iirc code from worldcookery book):
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: [Zope3-dev] Community opinion about workflow engine
Hi Godefroid,
CCing zope3-users, where this post belongs to.
On Monday 12 March 2007 11:48, Godefroid Chapelle wrote:
> - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow,
> OpenFlow...)
Kit asked the question about workflows on the SchoolTool list as well; I
assume that you guys are working together.
I have personally found that workflow engines are ususally overkill. In fact,
I think document/content publishing as it is done in Zope 2 CMSs is one of
the exceptions.
In SchoolTool we decided early to use a workflow engine to enforce process. We
have found there that it was overkill. (Everyone else can read Tom's comment
on the SchoolTool-Dev list.)
That said, here is my experience from another customer. This customer asked us
to rewrite a job application management software. You can easily see the
common workflows there. However, her complaint about the old system was that
the workflow was too stiff and she wanted to change the list of stati of a
particular application at any time manually, effectively breaking the
workflow.
With those requirements in mind we looked at our options, and she wanted to
deliberately break the flow we decided against any workflow engine. Instead,
we implemented stati as a special property of the application. Whenever the
stati are changed, we fire events for each added status and another event for
each removed status. We then created a module called "policy" that contains a
multitude of event subscribers listening to the events and doing the work.
Those tasks include writing logs, sending E-mails, triggering other status
changes, security changes, and data verification. Here is some of the
interesting code:
application:
class Application(Contained, Persistent):
...
@apply
def stati():
"""See IApplication"""
def getStati(self):
return self._stati
def setStati(self, value):
removed = set(self._stati) - set(value)
added = set(value) - set(self._stati)
self._stati = tuple(value)
for item in removed:
zope.event.notify(StatusRemovedEvent(self, item))
for item in added:
zope.event.notify(StatusAddedEvent(self, item))
return property(getStati, setStati)
policy:
@zope.component.adapter(interfaces.IStatusRemovedEvent)
def historyApplicationStatusRemoved(event):
log(
event.object,
_('Status Removed: $status', mapping={'status': event.status}))
# Not reacting to a status change, but nevertheless interesting to look at.
# Yes Martijn, I love hurry.query!
@zope.component.adapter(interfaces.IApplicationCompletedEvent)
def applicationCheckForDuplicate(event):
# When upon completion of the application, another application with same
# last name, first name and birth date is detected, then this application
# is marked as duplicate
app = event.object
duplicateQuery = query.And(
query.value.Eq(('app-catalog', 'firstName'), app.firstName),
query.value.Eq(('app-catalog', 'lastName'), app.lastName),
query.value.Eq(('app-catalog', 'birthDate'), app.birthDate),
query.query.Not(
query.set.AnyOf(('app-catalog', 'stati'),
(interfaces.INCOMPLETE,))
),
)
result = tuple(query.query.Query().searchResults(duplicateQuery))
# Only mark applications as duplicates, if the application is not itself
if (len(result) == 1 and app not in result) or len(result) > 1:
app.stati += (interfaces.DUPLICATE,)
So in fact, our workflow engine is the Zope 3 event framework. I like it for
the following:
- There is no new framework overhead; use what you know.
- It is maximally flexible. I have control over the way I implement the
business logic and the UI.
- Having all policy in one place (this includes event subscribers to other
events as well) provided great oversight. Whenever the customer asks
me: "What are the rules for this behavior?" (even though she specified it, of
course), I can just go to this one place and give her an answer within a few
minutes.
- Easy to test. It is very simple to test each event subscriber in isolation
and go through all the cases.
I guess I would not have to say it again, but I really like this pattern.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope 3 and menus
Dnia wtorek, 13 marca 2007 15:12, Tom Gross napisał: > Hi there, > > I override BrowserMenu from zope.app.publisher.browser.menu and add > a entry 'abs_action' to the resulting dictionary. Nice solution. Thanks a lot! -- Jakub Wisniowski ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] keeping GET data in a formlib based form
Hi everybody, I have a formlib based form. It is not accesible from an application menu because it is part of a wizard like process. The first time it gets called the url looks something like this: http://localhost:8080/myapp/mycontent/myform?myarg=23 So in the update() method of the form I read the myarg argument from the request and use it to setup some widgets in a particular way. The problem is that when the action buttons of the form are clicked, and the form is reloaded, the 'myarg' argument is lost and I run into problems. I need a way to keep 'myarg' information in my form for subsequent calls. Ideally I would like some mechanism that ends writing an tag in the html because that way my code: def update(self): [..] data = self.request['myarg'] [..] will still work, right? I have thought about extending the formlib template to just do that or maybe adding a form.Field to my form with a special Widget associated to it. No idea of what's the best aproach. Anyone has pointer for this? thanks Lorenzo Gil ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: [Zope3-dev] Community opinion about workflow engine
Hello Godefroid, I'm having a bit biased view, because I know just zope.wfmc and have the luck developing a pure Z3 application. I think with zope.wfmc you have - WFMC/XPDL support, you can shine with standards and big companies love standards - because it's XPDL support there's a graphical process editor jpEd - the core itself is quite sophisticated, but still misses some things for complete WFMC coverage (the WFMC spec is rather huge) - you can/should add some layers on top of it: - z3c.wfmcpersistent to store the processes in ZODB - ecm.workflow to have a higher level of APIs and functions (That was written by Roger Ineichen, but as nuxeo moved to jboss it was not maintained by them. Therefore I intend to move that code to z3c.wfmc, when I have some time to breathe. I have some improvements to the code. We even have plans to implement time management or scheduling with the package) All in all we're quite comfortable with zope.wfmc in our project. The project is about document management, also a bit of administrative thing. Monday, March 12, 2007, 4:48:24 PM, you wrote: > Hi all, > We have the opportunity to bid for a project concerning > the automation of administrative processes. > The client currently has software in Python and Zope/Plone. > They are quite explicit that they want their new applications to be > built as much as possible with a mix of generic shareable modules and of > custom modules. > This is a quite big project that, among others, includes the aspects of > collaboration with / support of the community. > One of the questions we are exploring is : "which workflow engine should > we use/expand on ?" > In order to help us make a proposal, we would be very interested to hear > your comments both > - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, > OpenFlow...) > - or about the directions that you would suggest in order to help you > use a given engine (missing features, simplification,...) and join the > effort to improve one of the existing engines. > Thanks -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
