 |
|
| |
|
|
|
|
|
|
|
So I have a idea for how apps string together. Now I need to think about how an app is written. There's also a question about letting a page see multiple apps. And while I think it, it would be good to have something componenty going on - so a page doesn't necessarily need to know about the apps that all the things on it use. Something in my brain just went squink. Apps, pages and components are all just request+model+logic->response objects. They are all components. Some dispatch, some decorate, some supply data, some generate pages. But lets be open-minded here - they're all the same thing! Point noted. Last evening, I abandoned a previous Page superclass and made LumpPage the top of the tree. I also made LumpPage a second-generation child of LumpNode, so that instead of
self.doc.add("foo")
you can just
self.add("foo")
Which is right. Doc and Page ought to be the same thing. Tags: programming
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
That's the word here. Proposition: requests get handed to applications, not pages.Applications can compose with dispatchers to feed the request on to a page. We could have a common dispatcher for standard cases. Differentiate between the site application and the others. Who has the job of querying the model? I still think it ought to be the page. Handler reads config (?) and creates site application. Handler turns apache requests into lump requests and passes them to site app Site app is given parsed config data (?) by handler and creates individual apps Site app dispatches requests - first by mapping rules to apps, then by mapping rules to pages, lastly by looking for matching pages in FS. No, acksherly, lastly by serving a 404 :) Every time a request is delegated, a list of the previous apps and the current app are passed in. (So in the first instance, handler->site, the list is empty. Then when site passes to "messageboard", the list contains one item, the site app. Then if messageboard passes to search, the lists contains the site and messageboard apps. In that case the request goes
Handler ->
Site app (dispatch on appmap) ->
MBoard app (dispatch on appmap) ->
Search app (dispatch on fs) ->
search.py (poppin' the stack) ->
Search app (poppin' the stack) ->
MBoard app (poppin' the stack) ->
Site app (poppin' the stack) ->
Handler
The app object can be like a mason-esque autohandler. It can also do authn/authz checking, All apps are entitled to perform authz checking Site app is responsible for main login and session management. We will provide a default SQL-backed lookup mechanism, session mechanism etc. These are composable strategies and can be reconfigured. But they should solve most people's issues An alternative might an OpenID handler. Tags: programming
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
Spent some time last night thinking about adding a layer of application to the system. What does "application" mean to me here?
- Pesistent data and ways to work with it (Data objects?)
- Application state (logged in, last visted etc)
- The model, i.e. the M in MVC
So: how should pages be linked to applications, and what form should the application take? Lets say the app is an object. Maybe it'll get more complicated. We might very well want more than one app on our site. E.g. a global app to cover user accounts, viewing preferences etc, with seperate apps for a calendar section, a weather report section, a message board section etc. Obviously any given page is going to have to be able to be part of more than one app. Possibly in a non-heirarchical way, too. There's a temptation here to use multiple inheritance. Define a subclass of LumpPage called WeatherPage, which knows about the weather app, and another one called MessageBoardPage, and then subclass both of them to make the WeatherBoardPage. Yeah, or not. "Favour composition over inheritance". Seems like it would make more sense to have pages pull in application objects at initialisation so they can just treat them however they see fit. Maybe
def __init__(self, req):
# ...whatever...
self.global = self.join_app("global")
self.weather = self.join_app("weather")
self.messages = self.join_app("messages")
super.__init__(self, req)
That's quite neat. The page can get whatever it needs out of the app object, but also the app can be given some authority over the page (maybe we could have a call chain?) In LumpPage.py:
def join_app(self, app):
self.apps.push(app)
def respond(self):
# wait, this isn't right
Application objects are going to "crappy singletons", in that each server thread will have its own one. I don't know what the implications of that are right now. Question: do we want to have to "register" apps in some way before they can be used? I mean, like having an equivalent of Java's web.xml, and listing our apps in there along with names and maybe parameters.
<site>
<app name="global">
<class>lump.global_app</class>
<param name="dsn">mysql://localhost/lumpdb?username=me&password=it</param>
</app>
<app name="weather">
<class>bigco.weather_app</class>
<param name="dsn">mysql://localhost/lumpdb?username=me&password=it</param>
<param name="default_loc">UK/Guernsey</param>
</app>
</site>
Thing is, why is it XML? Would it be easier to say, in the handler:
dsn = mysql://localhost/lumpdb?username=me&password=it
apps["global"] = (lump.global_app(dsn=dsn))
apps["weather"] = (bigco.weather_app(dsn=dsn, default_loc="guernsey"))
I mean, why invent an XML that nobody cares about? On the other hand, it feels right. Like you're making a very clear map of your system. More later on "web.xml-ism". Lets assume that pages are given a reference to the app list when they initialise. Ooh, wait, no! Let's give the *global* app more meaning - it's not just default, it's magic. Global app is responsible for all the others, whether it knows them personally or not. Your global app is your site. Your global app knows about your pages and all your other apps: it's your handle on the big picture. So in fact, in LumpPage.py:
def __init__(self, global):
self.apps.push(global)
def join_app(self, app_name):
global = self.apps[0]
new = global.get_app(app_name)
self.apps.push(new)
This is bogging down. Ned out. Lose Page class Allow modules to define class for themselves Sessions Tags: programming
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
Yeah yeah, posting thick and fast here, mostly because there's so much to catch up on. So here's my thoughts on a not-quite MVC framework: It needs to be easy to set up. So many frameworks have such a barrier to entry that I couldn't be bothered pursuing them. M-V-C seperation is good, but it's not the whole story. It doesn't match the technical reality of the web or the way people surf. You want a model, yes. That's a given. You want to respond to incoming requests, yes and produce a result, yes. But ultimately those two jobs are bound together. When you want to change a page, you want one file to edit, that queries the model and produces the output. I do not want to play hunt-the-code to make a quick change. Related, I want the URL that I see to be instantly and obviously related to a particular source file. I do not want to be second-guessing a request path -> FS path mapping system. Great, so far I've described PHP :-P So let me break it down a bit differently: when I construct my view, I don't want to have to do HTML. I reckon that "templating languages" ought to go away. If I'm writing Python, I want to describe my page in Python. And I want to describe it in a high-level way, using a suite of predefined elements. I want a modifiable DOM, not an incremental string. What I'm describing now is XML, isn't it? I want the page that generates my code to be adding units to an XML DOM, using a really easy, obvious, plain set of elements. When the XML page is done generating, I'll transform it into HTML. XML... transform... HTML? Wow, this sounds like a job for XSLT. And that's the extent of my concrete thought so far. I have implemented a simple mod_python handler which looks for a .py file matching the request URI under the docroot, loads it as a module, instantiates a class of the same name and asks it to deal with the incoming apache request object. This is complemented by a Page superclass with a template method. Concrete children (e.g. the class which actually make pages) are given the req object and expected to build a DOM tree, using a simplified API which makes stringing pages together dead easy (like, you can learn it in seconds). The template method then takes over and either applies my XSLT stylesheet before serialising the result and pumping it back to the client, or it adds a stylesheet processing instuction to the DOM, serialises it to XML and sends that to the client, leaving the browser to perform the transformation. How cool is that? The conceptual way of looking at this is: The Page object's responsibility is to describe a result document in a high-level way, including a general description of what appears on the page and the data needed to complete it. After that, anyone can transform the result into renderable HTML.It's already pretty cool, but I have a bunch more things to add, like some application-awareness, caching and data modelling. Tags: programming
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
What have I done recently? I started thinking about a new website. I want to use Python because it's so damn good. I'm also interested in breaking open the MVC mindset, because I don't think it's all the way there yet. I've been looking at Django, and a few others but I'm going to roll my own. Yet another website MVC framework? Just what the world needs. Well here's the thing: when one problem attracts hundreds of solutions, it usually means that none of them has got it right yet. As a point of comparison, far more people use WYSIWYG document editors than MVC frameworks, but how many implementations can you name? That anyone else has actually heard of? Word, Open Office, WordPerfect, AbiWord... we're reaching here. Likewise, open source relational databases. I can think of three that actually have any weight behind them (MySQL, Postgres and Firebird). Object-relational mapping systems, though? Hundreds of the bastards! What we have here is a period of rapid diversification as the community moves to fill a newly invented environment. Collectively, you might call things like MVC frameworks and ORMs the children of OO. Now that we generally understand OO, the implications and ideas come flooding in, and it will be a while before the dust settles and we can really see what was a good idea and what stank. There's a very good chance that the projects that come out of this development bubble smelling of roses won't exactly be implementations of any idea we've seen yet. MVC might be an idea they use, but it'll be in a better way. They might present an OO interface to data storage, but not in a table->object->table kind of way. Who knows. So I have no guilt about expanding the bubble even further. Maybe my ideas will die and rot and become part of the humous layer for the next generation - or maybe they'll be the next big thing ;-) Tags: programming
|
|
|
|
|
|
|
|
|
|
|
|
