ANNOUNCE: JOTWeb 1.11, preview of new web application system.

[Dave Cole]

>>>>> "Sean" == Sean Reifschneider <jafo-nclug at tummy.com> writes:

Sean> On Fri, Jun 20, 2003 at 11:11:48AM +1000, Dave Cole wrote:
>> If you mean developer when you say user then the developer is the
>> person designing the layout of the directory tree containing
>> code.py so it can be visible to the namespace mechanisms in JOTWeb.
>> This is still building up a namespace.

Sean> Ok, sure...  My point being that I think it's too much work in
Sean> Albatross to build up the name-space.  I was asked what I didn't
Sean> like about Albatross, and that's a large part of it.  I don't
Sean> like the way the name-space is built up, at least in the primary
Sean> examples.

Sean> We can get into semantic discussions and say that they're both
Sean> ways of building up the name-space, which is to an extent
Sean> true...  I just am not that fond of the way that the name-space
Sean> is set up in Albatross.

OK.  I think I have been arguing the wrong issue :-)

Maybe you objection to the namespace establishment is a subjective
dislike of the approach.  I have been arguing that objectively there
is not much difference in the amount of work involved in establishing
the namespace.  You will not get much disagreement from me on the
basis of subjective concerns.  If you just don't like it, then your
concerns are valid.

I don't mean the above in any kind of negative way.  I am strongly of
the opinion that there are many ways to approach this problem domain.

Sean> It really depends on what sorts of sites you're building.  I
Sean> would suspect that most sites have far more simple template
Sean> pages than they have complex pages.  I think we're probably
Sean> going to have to agree to disagree, though.

I must have been choosing my words badly.  I do not contend that
Albatross is better.  I am not sure that I even understand what we are
disagreeing about.

Sean> I, personally, find the notion of always having to build up this
Sean> main code that builds the name-space and render the page to be
Sean> similar to manipulating strings in C.  Sure, I can do it, but I
Sean> don't want to in most cases...

Sean> To me, it's like having to make a program that opens the file
Sean> and reads it, in order to have your .html page work with Apache.
Sean> Sure, it gives you more flexibility, but in most cases you just
Sean> want this thing to happen.

I don't see how the Albatross approach is analogous to the above.  Am
I missing something?  As far as I can tell the only difference in the
amount of code required to drive Albatross is an extra import
statement or two.

The expressions in the template files can use the global namespace of
the page module that runs the template.

    import code

    def page_display(ctx):
        ctx.run_template('time.html')

And here is the template:

    The current time is: <al-value expr="code.currenttime()">

So the only remaining difference I can see is that JOTWeb does not
have a page module.

Having said the above, it is possible to implement one extra class and
remove the requirement for page modules.  Consider the mixin classes
in this section.

    http://www.object-craft.com.au/projects/albatross/albatross/mixin-page.html

You could implement a mixin that stubbed out the page_enter() and
page_leave().  It would have a page_process() method that always did
the same thing rather than defer that process to the page module.
Finally the page_display() method could just load the template
identified by the page and run it.  Now you have an Albatross
application with no page modules.

I doubt that it would come out of the wash that easily (there are
other methods to implement).  I suspect that the mixin would have to
support page modules if they were present.

Sean> This seems to me a legacy of Albatross being a CGI, where that
Sean> CGI is the main entry point, instead of the HTML being the main
Sean> entry point.  So, you always have that code there.

Never thought of it that way, but I don't agree.  When I built
Albatross I wanted to make the templates subservient to the Python
code, not the other way round.  It really is that simple.

>> A issue with this (at least in my mind) is that the most obvious
>> use of the toolkit has it reaching its tentacles deeper into your
>> application.  I can see ways to work around this which means it is
>> not

Sean> I don't see that.

I mean that the application code in direct contact with the toolkit is
more granular with JOTWeb.

Sean> In my mind, the JOTWeb approach does some setup and then hands
Sean> control off to your presentation and code.  It's like having
Sean> Apache calling a CGI.  Apache sets up a bunch of environment
Sean> values and changes the directory, etc.  Then it calls into the
Sean> CGI.

Albatross is essentially the same except that the control is handed
off to the controller not the view.  Hmmm...  Would you characterise
JOTWeb as Model-View or Model-View-Controller?

>> providing the presentation and implementation components.  Whether
>> you import your code explicitly, or have it imported for you via
>> JOTWeb attributes is no big deal.

Sean> It was a big enough deal to me that I decided to try something
Sean> different.  That's all it boils down to.  And I very much like
Sean> the results...

I think that there is a lot to like in JOTWeb.  It has a clean design
and clear vision.

>> it the only thing that JOTWeb is saving over Albatross is one
>> import statement.  I am still maintain that is not a big deal.

Sean> According to the example that I created earlier, based on the
Sean> examples in the Albatross getting started documentation, it
Sean> required doing an import, setting up a function, setting up a
Sean> context, creating a name in the context, and then rendering the
Sean> page.  None of which I can remember how to do with Albatross.

Sean> JOTWeb, on the other hand, requires that you just create a
Sean> normal Python module and create a function which returns the
Sean> current time string.  Something that a Python programmer is
Sean> going to be hard pressed to forget...

True.

I wonder if the real difference between JOTWeb and Albatross is that
the Controller is mostly implicit in JOTWeb but explicit in Albatross.

>> If a developer finds the JOTWeb approach a more natural fit for
>> their application requirements and development style then that is a
>> win for them.  The same goes for Albatross.  I really don't think
>> there is a

Sean> You won't get any arguments there from me.  Again, I'm just
Sean> following up on what it was about Albatross that made me look
Sean> elsewhere.

The community is all the more richer for that.

- Dave

-- 
http://www.object-craft.com.au