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

[Dave Cole]

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

>> Again there is no argument here.  I might add that if the setup is
>> not purely exposing data to the templating then there is no way
>> that the toolkit will be doing that work for you.  That means that
>> the code has to be provided by the application and has to reside
>> somewhere.

Sean> Sure.  Along those lines, I'm adding to JOTWeb a way to set up
Sean> per-site startup scripts (probably of both HTML/TAL and Python
Sean> varieties, so that you can use whichever one is more
Sean> comfortable).  I'm tempted to add per-page "configuration"
Sean> because it would be easy, but it seems that it can be handled
Sean> directly in the HTML/TAL (tal:define) or in the normal python
Sean> modules.

>> If I read your comment correctly you are making the point that it
>> is preferable to glue the pieces of application code together by
>> references in the templates:
>> 
>> <span tal:replace="code/currenttime"></span>
>> 
>> which then implicitly imports code.py and invokes currenttime()

Sean> I don't really think that it makes sense to have the user have
Sean> to build up the namespaceto say what "currenttime" is.

I think I am getting confused now.  Does the above mean that JOTWeb
development is performed by both users and developers, or does it mean
that all developers who use JOTWeb to build applications are users of
JOTWeb?

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> It just makes sense to me that if you ask for the "currenttime"
Sean> attribute of the "code" entity, and you have a module called
Sean> "code" which contains a function "currenttime", that you (as an
Sean> application framework) can go ahead and call that for the user,
Sean> instead of making the user go through the extra step of creating
Sean> a context, importing the module, and setting up a name in the
Sean> name-space...

All true.  But you are still building a namespace.  I still go back to
me original point - if you are building an application with more
functionality than simply poking values into templates then this is a
minor issue.

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
such a big deal.

Maybe I should try to explain where I am coming from.

I firmly believe that for all but the most trivial of applications you
need to separate the presentation and implementation.  This allows you
to develop and modify the one aspect of the application mostly without
breaking the other.  Initially the effort is higher as you trade both
elements off against the other until an effective interface emerges.
In the medium to long term though, the separation yields savings.

Mind you there is no need to separate implementation and presentation
if your application is all presentation.

Assuming that we are talking about the same thing here, and there is
some implementation component of the application, then it is
worthwhile separating the two elements.  Once you have separated the
two elements you need some mechanism to connect them.  In Model View
Controller (MVC) talk, the view is the presentation, the model is the
implementation, and the connecting code is the controller.

In building a non trivial MVC application (especially a web based
application), the vast majority of the effort goes into building the
model and the view.  Relatively speaking the controller pales into
insignificance.

Having said that maybe I can go back and make my point again.
Toolkits such as JOTWeb and Albatross provide a framework in which you
implement your glue or controller.  You are still responsible for
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> Big Deal or not, it seems to me that like 90% or more of the
Sean> time when you have a template and somebody references it, you
Sean> want to provide a name-space and render it.  I put a template
Sean> there for a reason -- to be rendered to the browser.  I really
Sean> believe that if that is such a common case, that the user
Sean> shouldn't have to do anything special to make it happen.

But they do need to do something special.  They need to place the code
into a module so it can be imported by JOTWeb.  When it comes down to
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> It's no big deal to specify time.localtime(time.time()) as the
Sean> argument to strftime(), but I definitely think that making that
Sean> the default was a good thing...

>> From your example above, JOTWeb takes a much finer grained approach
>> in that the template identified by the browser request pulls in
>> Python code fragments from a namespace structured by the file
>> system.

Sean> That's what it boils down to...

Sean> It seems to me, now, that you could do the same thing with
Sean> Albatross, using a default handler with mod_python and
Sean> overriding the context.

I am not sure I follow here, but you are probably right.

>> When you make something implicit you remove some flexibility from
>> the application developer.  I imagine you wondered from time to
>> time when

Sean> I'm not sure that I agree that making something implicit
Sean> prevents it from being overridden.  So far, in the development
Sean> I've done with JOTWeb, I haven't really run into a case where I
Sean> wanted to change the default behavior in a way that required me
Sean> to override the default rendering code, yet still have it do
Sean> template rendering.

I hope that my discussion above clarifies what I was trying to say.  I
think that each approach has merit.  Both toolkits provide a way to
cut down on the amount of code you need to write in order to deliver a
web application, and both provide a framework for organising your
application code.  This is a big win for the developer.

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
killer framework that is suitable for all applications.

- Dave

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