[XML-SIG] Re: Re: Maki: great!

[Sam Brauer]

> From: "Alessandro Bottoni" <abottoni@quadrante.com>
> To: <xml-sig@python.org>
> Subject: [XML-SIG] Re: Maki: great!
> Date: Wed, 20 Feb 2002 16:44:26 +0100
>
> Messaggio in formato MIME composto da pi=F9 parti.
>
> ------=3D_NextPart_000_0011_01C1BA2D.DBB7B930
> Content-Type: text/plain;
> =09charset=3D"iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> See my comments below...
>
> > Date: Tue, 19 Feb 2002 14:51:39 +0100
> > To: xml-sig@python.org
> > From: Alessandro Bottoni <abottoni@quadrante.com>
> > Subject: [XML-SIG] Maki: great!
> >
> > I just discovered Maki (http://maki.sourceforge.net/), thanks to =3D
> Nicolas
> > Chauvat. Please, allow me to congratulate Sam Brauer for this very
> > interesting project and thank him for having donated this high-quality
> > software to the public domain.
>
> Thanks for your enthusiastic comments!
> I'm a little embarrassed (as I feel that the documentation, examples, =3D
> and
> packaging of the project are less than adequate).
>
> [Alessandro Bottoni]
> Everything can be improved but I think you did a wonderful work so far =
=3D
> :-)
>
> >
> > Now, a few comments:
> > 1) I found interesting the idea to use embedded Python code for =3D
> creating
> > dinamic XML pages. I think this solution is simpler and probably =3D
> faster to
> > process than the complicated XSP (XML Server Pages) used by Cocoon =3D
> (see:
> > http://xml.apache.org/cocoon) but I would like to hear the opinion of =
=3D
> the
> > other partecipants of this list regarding this topic. Is an embedded
> > scripting language better than a XML-compliant page format for =3D
> creating
> > dinamic web pages? How about content/logic separation? How about =3D
> developer
> > friendliness?
>
> I find it to be quite developer friendly.  You can make changes and test
> them very quickly, and you have the full power of Python at your =3D
> disposal
> to produce the dynamic content.
>
> [Alessandro Bottoni]
> I agree completely. In particular, having the full power of Python at =3D
> your fingertips makes Maki much more flexible and powerful than most =3D
> PHP-based systems.
>
> Regarding content and logic separation, you can make them quite separate
> by writing logicsheets (or "taglibs") that are specific to your project.
>
> [Alessandro Bottoni]
> Great! That is exactly what I hoped to hear from you!
>
> For example, on a project I am working on now I have a database
> abstraction layer that maps Python objects to tables in a SQL database.  =
=3D
> I
> have written various methods that allow me to retrieve objects that =3D
> match
> certain conditions, and each class has a method toSaxEvents(handler) =3D
> that
> writes out a representation of the object via SAX events.  (When maki
> evaluates objects to serialize them into an XML document, it tries to =3D
> call
> toSaxEvents() if the object has such a method, otherwise it uses a
> default method that handles built-in Python types in a sane manner and
> calls str() on objects without a toSaxEvents method.)
>
> [Alessandro Bottoni]
> Quite interesting... Do you plan to make this module avalaible as open =
=3D
> source software, as well?

It's a bit too quirky.  I don't think it's generic enough that
other people could easily use it.  I wrote my own only because I never
found a database abstraction layer that really suited me.

If you look around, there are a lot of database abstraction api's.  If you
find one that you like, you can write a wrapper around it or subclass it
such that the storable objects have a toSaxEvents() method.  Then write a
logicsheet that uses that api, and you're set to use it with maki.

>
> In xml documents to be processed by maki, I _could_ directly embed =3D
> Python
> code that operates on the objects and adds them to the document by =3D
> running
> a process step.
>
> Or I can make up a set of tags that declare what objects I want to
> retrieve (including a list of conditional and/or sort criteria expressed
> by multiple nested tags, for example).  In that case, I would write a
> logicsheet (xsl stylesheet) that matches those tags and transforms them
> into maki tags that execute and evaluate the Python code necessary to
> retrieve those objects.  My input XML documents can then contain my =3D
> custom
> tags, and I can pass the document through a stylesheet step that =3D
> replaces
> those tags with the maki tags, then pass that output into a process =3D
> step.
>
> If you use a logicsheet approach like this, you can achieve a high =3D
> degree
> of content/logic separation, since your input xml documents declare what
> content you want and leave it up to your logicsheet to actually do the
> work to get the content.
>
> [Alessandro Bottoni]
> Maki could became the core of a future, full-blown "portal system", like =
=3D
> PHPNuke or ezPublish. This depends strongly on the possibility to =3D
> develop add-ons, plug-ins, modules and extensions in a easy and fast =3D
> way. For this reason, I think that the adoption of this =3D
> stylesheet/taglib-oriented approach is crucial for the future of Maki. =
=3D
> Can I suggest you to develop a small example of such a solution? This =3D
> would help us a lot in understanding the implementation details and in =
=3D
> keeping ourselves coherent with the existing architecture.

maki comes with some example logicsheets.  One provides a set of tags that
allows you to embed SQL queries in your pages and inserts the results as
several nested elements in the page.  Another provides a tag set for
obtaining data from an HTTP request.
Example pages that use both of these are installed with maki.

I would like to include more examples, but nothing so elaborate as a
portal.

>
> maki doesn't force you to do it either way.  You have the flexibility to
> decide what best suits your needs.
>
> In general I tried to write maki such that it would be flexible and not
> force any particular style of usage.
>
> >
> > 2) On the basis of Maki, it would be a very good idea to develop a =3D
> "Portal
> > system" like "Cocoon Portal" (see:
> > =3D
> http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstLook.html)=
=3D
> .
> > This would make much easier and faster to create Python/XML/Maki-based =
=3D
> web
> > sites and would allow for a wider acceptance of these technologies. =3D
> Anybody
> > is thinking/working on such a system?
>
> That looks pretty neat.  I'm sure one could create something similar on
> top of maki/mod_python.  I haven't thought about it myself (and don't
> really have the time or immediate need to).
>
> [Alessandro Bottoni]
> I think that a system like "Cocoon portal" is what the real-world web =3D
> developers really need (python-based, of course...). They do not have =3D
> time to study a complex XML-based system, like Cocoon,  and develop a =3D
> web application from scratch. They need a full-blown, empty portal that =
=3D
> they can easily install and adapt to their specific needs. That is =3D
> exactly what PHPNuke and ezPublish give them at the moment. I will try =
=3D
> to develop such a system, using Maki as a basis, as soon as I will have =
=3D
> some more freetime (currently, I'm involved in a very demanding, =3D
> security-related project. I have no time for anything else). I will keep =
=3D
> you (and the other, possibly interested, people in the list) up-to-date =
=3D
> about this project. If someone else is fascinated by this idea, please =
=3D
> do not wait for me: I could be blocked for months...

As other people have pointed out on this list, there are already
Python-based portal systems you could use.  To write a maki-based one
that's comparable would not be a trivial undertaking.  I'm sure it could
be done, but I'm not going to do it unless I need to create a portal site
for a client and find that the existing systems don't suit my needs.

If you write one, I would definitely check it out :)

>
> >
> > 3) Does anybody use Maki in a production environment?
>
> So far I've only used it in a production capacity for intranets, =3D
> although
> I'm in the process of creating a rather large scale public site on it.
> Whenever that goes live (which won't be until late summer or early fall)
> I'll most likely announce it on the maki homepage.
>
> > How about performance
> > and stability?
>
> maki itself seems to be quite stable if the software it depends on
> (mod_python, Python, and whatever xslt extension(s) you use) are stable
> and installed correctly.
> Similar with performance...  If your xslt processor is fast and the =3D
> Python
> code your pages execute is fast, then your site should perform well.
>
> libxslt is the fastest xslt processor I've used under Python so far.
> Unfortunately at the moment I am having trouble trying to use it with
> maki.  Hopefully this will clear up soon as development on the two =3D
> Python
> interfaces to libxslt continues.  In the meantime, I'm using Sablotron =
=3D
> and
> it's pretty speedy.
>
> Regarding speed of Python code, I'm finding that trying to achieve high
> performance and at the same time achieve a high separation of content =3D
> and
> logic can be tricky.  Adding layers of abstraction to your code tends to
> make it slower.  Logicsheets can hide a lot of the complexity, but =3D
> become
> rather complex themselves if the code they make calls to is not very
> abstract.
>
> [Alessandro Bottoni]
> I expected it: Content/Style/Logic separation came at a cost. In any =3D
> case, Python-based systems seems to be faster than java-based ones, like =
=3D
> Cocoon.
>
> To wrap up, you are taking a risk by using maki (since I haven't even
> deployed it yet on a large scale public site), but I hope that doesn't
> prevent people from trying it out.  It should only get better over time.
>
> - Sam Brauer
> http://maki.sf.net/
>
> [Alessandro Bottoni]
> I can just speak for myself but I think that Maki is already giving us =
=3D
> what we actually need: a robust, elegant, modular system that we can use =
=3D
> as a skeleton for developing a full-blown portal system like "Cocoon =3D
> portal", PHPNuke, ezPublish and so on. If we can leave most of the =3D
> "general purpose" tasks (XML/XSLT management, session management, DB =3D
> abstraction layer, etc...) to Maki, we can focus on creating =3D
> task-specific "modules" (article publishing, poll management, calendar, =
=3D
> etc...) that will eventually sum up to a real, full-featured portal =3D
> system. That would be a really great achievement, in my opinion.
>

maki does handle running the XSL transformers for you, and allows you to
run your XML through SAX-based processors (either custom ones that you
write or the included one that evaluates embedded Python code), and
provides a rule-based system that allows you to configure the steps to
apply to a given file, and does all of the I/O to handle the HTTP
transaction and read the XML/XSL files, and cache output.
Any other functionality (such as session management) is outside of
the scope that I want for maki.
The example SQL logicsheet can be used as a simple read-only database
abstraction layer, but isn't intended to be _the_ way to interact with SQL
databases from maki.

I'm using maki right now to do a site that has all the tasks you listed
(article publishing, poll management, calendar, etc).  What I like about
maki is that it provides a great framework on which to build these
things, and it's generic enough that one could build almost any type of
webapp on it.  But writing webapps that are generally reusable for many
websites is hard.   The next time I have a need for an article publishing
system, I'll probably use the one I'm writing now as a starting point.
But I'm sure I'll have to make modifications so that it suits the needs of
the next project.  Though both sites have a concept of articles and a need
to publish them, each site may have very different concepts of what
constitutes an article, or how articles should be categorized, or how
articles can be related to other articles, etc.
Gee... I'm getting depressed now.  On the positive side, at least there's
job security in knowing that there's always more custom work to do ;)

- Sam