> > 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. Brandon, I like your enthusiasm towards Plone :) My rationale * End users bring money * End users cannot be educated * Site managers can be educated * I am willing to improve the end user user experience at the cost of site manager user experience * Web best practices say that friendly URLs are must. * Friendly URLs will increase the trust towards the shop * @@ does not look friendly in URL. * /getpaid-checkout does not look as friendly as /checkout in URL * You cannot create conflicting id in Plone, though the error messages are sometimes little cryptic (name is reserved, cannot paste, etc.). * Possible conflict with content ids and view ids is not GetPaid's problem - it is a generic problem. Plone has a good community and solves problems sooner or later (years). -- Mikko Ohtamaa http://www.twinapex.com - Python professionals for hire > > > > 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 -~----------~----~----~----~------~----~------~--~---
