Wyatt Baldwin wrote: > On Jan 12, 9:32 am, mk <[email protected]> wrote: >> Jonathan Vanasco wrote: >>> The Original Poster was not talking about a WEB API for REST/JSON, he >>> said Command Line API >> Well I'm the OP here. :-) Anyway, if I understand correctly, Chris >> suggested outputting JSON to a scripting client, which would work like this: >> >> - scripting client calls normal URIs in the web app over http, but would >> set "Accept: application/json" header in the request. > > No. Use application/json when you want to call your web app as a web > service.
Basically, that is what I want -- I imagine PHP library writers will see this as proper solution for communication with my app (as opposed to doing unreliable tricks like sshing to the managed host and calling cmdline tool). >> - web app understands that if above header is set, it should output >> JSON, which is then parsed by the client's JSON reader. >> >> IOW, if I understand correctly, Chris suggested that scripting library / >> commandline tool should be a thin wrapper around code producing HTTP >> requests and parsing JSON replies (right?). > Though it's an interesting idea, I doubt you want your command line UI > to call your web app over HTTP. Well it may make sense actually -- I haven't checked that out yet, but I think at least some of my prospective customers would actually like to run the cmdline ui on a host different than the one that hosts the app. > You need to think about separating your "core" functionality from your > user interface(s). When I start a new project, I always create a core > package containing my model and services. I then create separate > packages for the various UIs I might need. I guess you put it all in app/lib? > There's different ways to do this. You could create namespaced > packages (search for discussion in this group) or you could create a > single package with, for example, core, model, and ui subpackages. > The key thing is, any core functionality should be separated from your > UI. For example, in a Pylons project, you don't want functional code > in your controllers. The controller should only parse form data, hand > it off to the core for processing, and select the next view. Sorry for bothering you more, but how exactly you communicate between controller and core code? Raise exceptions in core modules and catch them in controller? > Now, for a simple web app, some might argue that this is overkill. In > the end, _you_ have to decide, but structuring your project from the > start with separation-of-concerns in mind doesn't cost much time or > effort. > Another thing to consider is that FormEncode is aimed at HTML form > processing, so it may not be the best choice for validating inputs for > a command-line interface. > > I don't have the final answer on all this, but I hope this helps a > bit. It does. Thanks! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
