On May 25, 11:52 am, DD <[email protected]> wrote: > Hi, > I run a pylons-based website, and we are now planning to expand to > mobile web and also expose an API. > > I have written the site in a standard pylons way: > Models + logic + controllers + templates > > Controllers do all the validations/rendering/etc, while logic implements > the actual functions to do the actions like creating an account or > searching for something. My models classes are pretty light weight with > almost nothing in them except class definitions for various database tables. > > Now, as I am planning to have different front-ends to the website (api > and mobile), i am looking at what might the best practices for doing > this. Basically, I can move everything to logic, and throw exceptions > from there, but I would ideally like to keep logic separate from any > web-related stuff (like requests or cookies). > > What I am leaning towards right now is to create a set of 'logic > controllers', which does all these things, and then extend the actual > controllers for web/mobile/api from there. I will still have to figure > out how to deal with validators and such, as formencode @validate is > helpful if you use HTML or similar. > > Any suggestions will be great!
I separate the model into a completely separate package. This isn't strictly necessary, but it makes it completely clear that the model is not specific to any particular application or environment. It also makes it easier to share model classes with coworkers who are writing other applications that need access to the same classes/tables. I've played with the notion of "services" (what I believe you're calling "logic" above), but so far I've implemented most of that logic within the model itself. I do have a couple of packages that just "do stuff", but these are more like utilities than services (although, what's the difference?). On top of that model, I create a Pylons-based, RESTful Web services package that provides a standard interface to all the model classes I want to expose. This package contains only WS controllers--no templates, static files, no Web session, etc. I do use FormEncode here, though, when it seems appropriate. At this point, you can write a command line script using your model while ignoring any Web-related stuff. Or, maybe your script talks to your model through Web services; whatever floats your boat. You can also build a Pylons Web app that uses the aforementioned WS package for some or all of its AJAX needs. This app contains all your static files, templates, Web sessions, and what not. I see it largely as a front end to your model (either via Web services or directly, as appropriate). It validates form data and parses it into something your model can handle. And, of course, it's the delivery vehicle for your application's public-facing Web UI. All of this might be overkill for certain situations, but it's possible to collapse all these packages into a single package that follows the same ideas. You'd create a ws/ subpackage in your controllers directory. You'd put your model classes in the models/ directory; just make sure no Web-specific stuff goes in there. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
