Webware for Python

Is there a way to get a url to map to a Python servlet of a different
name?  In particular, I'm hitting naming conflicts with MiddleKit
objects (which I'd like to give nice names), and servlets (for which I
want to have a URL to match the MK object they display).  So, it would
be nice if I could rename the source files/classes and maintain the
same URL.

  Ian

Re: [Webware-discuss] Servlets by other names... From: Chuck Esterbrook <echuck@mi...> - 2001-04-26 01:27 At 06:53 PM 4/25/2001 -0500, Ian Bicking wrote: >Is there a way to get a url to map to a Python servlet of a different >name? In particular, I'm hitting naming conflicts with MiddleKit >objects (which I'd like to give nice names), and servlets (for which I >want to have a URL to match the MK object they display). So, it would >be nice if I could rename the source files/classes and maintain the >same URL. Interesting. Before we come up with a hack, perhaps there is a fundamental problem here. Your middle classes have to be in your sys.path so that the "from Foo import Foo" statements found in the generated code will work. But what about your servlets? I thoughts Geoff's somewhat recent modification to ServletFactory.py and company eliminated the need to augment sys.path. If that's not the case, then I guess the reason I don't run into the same problem you have is just a style thing. If my system has Books, then my context has: MyApp/ Books/ Main.py # browsing, select for edit, delete, etc. Edit.py View.py Delete.py Getting back to your problem, do you know exactly why the naming conflict occurs? My first thought is that it shouldn't. Are your middle classes in a directory separate from the context? Another thought, which is valid regardless of whether or not we solve your problem in other ways, is that MK should allow for code generated that does "from foo.bar.Baz import Baz" where "foo.bar" comes from a config file setting. That would allow you to treat your middle classes as a Python package. -Chuck

Re: [Webware-discuss] Servlets by other names... From: Ian Bicking <ianb@co...> - 2001-04-26 02:44 Chuck Esterbrook <echuck@...> wrote: > Interesting. Before we come up with a hack, perhaps there is a fundamental > problem here. Your middle classes have to be in your sys.path so that the > "from Foo import Foo" statements found in the generated code will work. > > But what about your servlets? I thoughts Geoff's somewhat recent > modification to ServletFactory.py and company eliminated the need to > augment sys.path. Are those changes in 0.5rc2? I tried moving the MK objects into their own directory, and I'm still getting the problem (i.e., importing the servlet instead of the object), so the servlet directory must be further up the path than the MK directory. > If that's not the case, then I guess the reason I don't run into the same > problem you have is just a style thing. If my system has Books, then my > context has: > > MyApp/ > Books/ > Main.py # browsing, select for edit, delete, etc. > Edit.py > View.py > Delete.py I prefer to use the path to express which object, so the path might look like: /MyApp/Book/Poetry Where Poetry is used to identify the object. I think it's a nice URL (nice URLs were something I really liked about Zope). I can't decide whether I prefer /Book/Edit/Poetry, /BookEdit/Poetry/, or /Book/Poetry/Edit... but I digress. Anyway, it doesn't make sense to pluralize Book here, so I get a name conflict. > Getting back to your problem, do you know exactly why the naming conflict > occurs? My first thought is that it shouldn't. Well, it confused me a bit, since it imports the servlet in place of the MK module/object and gives an error about not having the initFromRow method. > Are your middle classes in a directory separate from the context? It wasn't, but I changed it and it still happens. > Another thought, which is valid regardless of whether or not we > solve your problem in other ways, is that MK should allow for code > generated that does "from foo.bar.Baz import Baz" where "foo.bar" > comes from a config file setting. That would allow you to treat your > middle classes as a Python package. I think that's a better solution. There's already a lot of things in the path, with other potential name conflicts. Putting the MK objects in their own namespace seems like the Right Thing To Do. Ian

Re: [Webware-discuss] Servlets by other names... From: Chuck Esterbrook <echuck@mi...> - 2001-04-26 03:03 At 09:44 PM 4/25/2001 -0500, Ian Bicking wrote: >Chuck Esterbrook <echuck@...> wrote: > > Interesting. Before we come up with a hack, perhaps there is a fundamental > > problem here. Your middle classes have to be in your sys.path so that the > > "from Foo import Foo" statements found in the generated code will work. > > > > But what about your servlets? I thoughts Geoff's somewhat recent > > modification to ServletFactory.py and company eliminated the need to > > augment sys.path. > >Are those changes in 0.5rc2? Uh, no. I'm pretty sure those are only in the main CVS branch. They came too late and were too big to make it into 0.5.1. >I tried moving the MK objects into their own directory, and I'm still >getting the problem (i.e., importing the servlet instead of the >object), so the servlet directory must be further up the path than the >MK directory. I think going Webware CVS is really your next step. >Where Poetry is used to identify the object. I think it's a nice URL >(nice URLs were something I really liked about Zope). I can't decide >whether I prefer /Book/Edit/Poetry, /BookEdit/Poetry/, or >/Book/Poetry/Edit... but I digress. Anyway, it doesn't make sense to >pluralize Book here, so I get a name conflict. Understood. BTW I like Book/Poetry/Edit. You might as well string the nouns together and typically most apps have you browse "objects" until you find what you want and then you apply an action to them. Like Word, Excel, Illustrator, etc. What if you want to manipulate multiple items? That's what the GET args gives you: Books/Preview?ids=45+78+97 > > Getting back to your problem, do you know exactly why the naming conflict > > occurs? My first thought is that it shouldn't. > >Well, it confused me a bit, since it imports the servlet in place of >the MK module/object and gives an error about not having the >initFromRow method. Uh, yeah. initFromRow is a msg sent to descendants of MiddleObject. It's hitting the servlet first, creating it and then sending it that non-servlet message. Both servlets and middle objects can be created with no args to the constructor. I suspose it should check for issubclass(someClass, MiddleObject) first which would give a more meaningful error at an earlier time. > > Another thought, which is valid regardless of whether or not we > > solve your problem in other ways, is that MK should allow for code > > generated that does "from foo.bar.Baz import Baz" where "foo.bar" > > comes from a config file setting. That would allow you to treat your > > middle classes as a Python package. > >I think that's a better solution. There's already a lot of things in >the path, with other potential name conflicts. Putting the MK objects >in their own namespace seems like the Right Thing To Do Agreed. But we also needed this for WebKit and already did it. One down. One to go. -Chuck

Re: [Webware-discuss] Servlets by other names... From: Ian Bicking <ianb@co...> - 2001-04-26 05:59 Chuck Esterbrook <echuck@...> wrote: > Uh, no. I'm pretty sure those are only in the main CVS branch. They came > too late and were too big to make it into 0.5.1. Okay, now I'm working with the CVS version. Still get the problem. Here's what sys.path looks like when it does the import: ['/usr/home/ianb/public_html/Webware/WebKit/Sarah', '', '/usr/lib/python2.0', <a bunch of other system paths>, '/usr/home/ianb/public_html/Webware', '/usr/home/ianb/public_html/Webware/WebKit/Cache/PSP'] To do the import I added a function to my SitePage: def store(self): if not hasattr(self, "_store"): self._store = MySQLObjectStore(user='root', passwd='inter') self._store.readModelFileNamed(os.path.join(os.path.dirname(self.request().serverSidePath()), 'MK/Gallery')) return self._store So I've given it the file: /usr/home/ianb/public_html/Webware/WebKit/Sarah/MK/Gallery But Sarah/MK hasn't been added to the path at all. > >Where Poetry is used to identify the object. I think it's a nice URL > >(nice URLs were something I really liked about Zope). I can't decide > >whether I prefer /Book/Edit/Poetry, /BookEdit/Poetry/, or > >/Book/Poetry/Edit... but I digress. Anyway, it doesn't make sense to > >pluralize Book here, so I get a name conflict. > > Understood. BTW I like Book/Poetry/Edit. You might as well string the nouns > together and typically most apps have you browse "objects" until you find > what you want and then you apply an action to them. Like Word, Excel, > Illustrator, etc. Yes, I prefer this too -- it's more difficult, because then servlets don't quite map by URL. But that's just an annoyance, not a serious problem. > What if you want to manipulate multiple items? That's what the GET args > gives you: > > Books/Preview?ids=45+78+97 I'd do Books/Preview?id=45&id=78&id=87 -- But, yes, that's a problem. The hierarchical URL simply can't represent collections. Could you use forwardRequest to call Preview over and over for each ID? Either way you don't get repetition for free, and I don't think it's a big burden to support URL and GET variables. > Uh, yeah. initFromRow is a msg sent to descendants of MiddleObject. It's > hitting the servlet first, creating it and then sending it that non-servlet > message. Both servlets and middle objects can be created with no args to > the constructor. I suspose it should check for issubclass(someClass, > MiddleObject) first which would give a more meaningful error at an earlier > time. That would be helpful -- just an assert right after the import, probably. The error message confused me a bit. Ian

Re: [Webware-discuss] Servlets by other names... From: Chuck Esterbrook <echuck@mi...> - 2001-04-27 15:28 At 12:59 AM 4/26/2001 -0500, Ian Bicking wrote: >Chuck Esterbrook <echuck@...> wrote: > > Uh, no. I'm pretty sure those are only in the main CVS branch. They came > > too late and were too big to make it into 0.5.1. > >Okay, now I'm working with the CVS version. > >Still get the problem. > >Here's what sys.path looks like when it does the import: [1] I haven't forgotten about this problem. [2] I think I just ran into it in my project, which means you're in luck, because now we're in the same boat! :-) I'll be back with more, later. -Chuck

1 message has been excluded from this view by a project administrator.