Mikko Ohtamaa <[email protected]> writes:
>> seems like a good opportunity to rename it to just @@checkout-wizard
>
> You can also drop @@. ... So you can just have:
>
> /enter-shipping-address
> /choose-payment-method
> /final-checkout
Which brings up some great questions! :-)
First, just to make sure everyone knows the difference, the URL
"/Plone/foo" can mean *two* different things. First, it might bring up
some item inside of the container "Plone", like a Folder or Page or
whatever, that happens to have the ID of "foo". Second, it might find
that there is a view registered for "Plone" objects that is named
"@@foo", and display that view of the Plone object instead.
So the @@-less URLs suggested above will only work if we can *guarantee*
that Plone users will not create top-level folders with the same name.
Try it on a sample instance of your own: first, observe that
"/Plone/empty-cart" shows you the GetPaid empty-cart view, just like the
similar URL "/Plone/@@empty-cart". Now, go into "/Plone" and create a
Page named "Empty Cart". What happens? The "/Plone/empty-cart" URL now
shows the page you've created, and GetPaid, if it was relying on that
URL, would be broken.
But, of course, even if we can stay out of the way of users, we still
have other developers to contend with! What if (I'm being a bit silly,
just for illustration) someone writes an Oregon Trail clone for Plone
and has an "empty-cart" view for what happens if your supplies get
stolen? Then, depending on which view gets registered first (or would a
conflict message be generated by the duplicate registration?), only one
of the two plugins could work on any given site.
I suspect that this is why the best of the GetPaid views have their
names start with "getpaid-*"; that way, they're pretty much guaranteed
to be unique, and not conflict with other views that other products have
registered. And if we do conflict, we can easily blame the other guy,
for starting their view with the name of our product. :-)
All of this raises a second question besides the question of whether
names are likely to collide: does it strike anyone else besides me as
extremely strange that the "@@empty-cart" view is *not* merely a view of
a Plone site, but a view of *any possible object whatsoever*? Try it!
Create a new Plone instance with GetPaid, and try visiting these URLs:
"/Plone/@@empty-cart"
"/Plone/news/@@empty-cart"
"/Plone/events/@@empty-cart"
"/Plone/front-page/@@empty-cart"
These are *all* aliases for the same view! Why? Because, crazily, the
ZCML declaration for "empty-cart" goes like this:
<browser:page
for="*"
template="templates/cart-empty.pt"
name="empty-cart"
permission="zope2.View"
/>
In other words, the "empty-cart" view is declared to be an appropriate
view for "*": for ANYTHING!
This seems to be an utter abuse of the concept of a view. Views are
supposed to get data, and display it. Like these views:
"/Plone/@@folder_contents"
"/Plone/@@manage-content-rules"
"/Plone/@@sharing"
These are views that are working as they ought! They are taking an
object for which they are designed - in this case, the "Plone" container
- and render it in some useful fashion that lets it be viewed or
modified.
Why does "@@empty-cart" need to exist everywhere beneath a site? Why
should hundreds of URLs for it be valid?
This approach will also get us into trouble if we want to make these
views available under other frameworks, like Pylons or Turbogears or
Django. Under those systems, when someone wants to provide a plug-in
system, they generally just ask for *one* plug-in point beneath which
their URLs exist. The integrator gets to select "/getpaid", or
"/cart", or "/checkout", or whatever they want, and then all of the
plug-in URLs exist under there. The Plone approach - of creating dozens
of new views, of "dumping" them into the global URL space and just
hoping there will be no collisions, and of registering them for every
object under the sun so that they exist beneath every valid URL on the
web site - is, if I can use this word politely, just bizarre. :-)
What solution might we consider for this chaos?
It occurs to me that views can be registered against all objects that
happen to offer a certain interface. What if we registered all of our
views for="IStore"? All sorts of good results would seem to follow:
(a) Only those sites in a Zope instance that have actually installed
GetPaid and been marked as IStores will have the GetPaid views
activated for them. If "/Plone1" has GetPaid installed but
"/Plone2" does not, then only the former will have a shopping-cart
view.
(b) GetPaid views will only exist at each store's root, rather than
being crazily duplicated everywhere.
(c) When we go to offer GetPaid as a solution under more conventional
web frameworks, all we've got to offer is a way for, say,
"/getpaid" under their Django site to return a Zope "IStore"
object and start up the Zope traversal logic, and, bingo!, all of
our views will be accessible as "/getpaid/checkout",
"/getpaid/enter-shipping-address", and so forth. Trust me: no
normal web framework will consider us unless we can behave nicely,
by placing all of the new URLs we create down beneath a designated
name the guarantees we won't conflict with their other URLs. :-)
This doesn't seem to solve the problem of keeping our view names from
colliding with other site-level views in a Plone site; but, Plone people
seem to be living with the current situation without complain, so I'm
fine for now if no one else has a problem with "/Plone/@@checkout" being
where we put the checkout wizard. Heck, I guess if we document the
restriction, we could even have "/Plone/checkout" be what we named it.
Maybe Plone people are much more careful and alert about not creating
conflicting names than I'm imagining, and it's not something we should
worry about? Speak up, Plone folks, and help me understand how you live
with all of this.
--
Brandon Craig Rhodes [email protected] http://rhodesmill.org/brandon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"getpaid-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
