[XML-SIG] Re: Maki: great!
Alessandro Bottoni
abottoni@quadrante.com
Wed, 20 Feb 2002 16:44:26 +0100
Messaggio in formato MIME composto da pił parti.
------=_NextPart_000_0011_01C1BA2D.DBB7B930
Content-Type: text/plain;
charset="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 =
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, =
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 =
:-)
>
> Now, a few comments:
> 1) I found interesting the idea to use embedded Python code for =
creating
> dinamic XML pages. I think this solution is simpler and probably =
faster to
> process than the complicated XSP (XML Server Pages) used by Cocoon =
(see:
> http://xml.apache.org/cocoon) but I would like to hear the opinion of =
the
> other partecipants of this list regarding this topic. Is an embedded
> scripting language better than a XML-compliant page format for =
creating
> dinamic web pages? How about content/logic separation? How about =
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 =
disposal
to produce the dynamic content.
[Alessandro Bottoni]
I agree completely. In particular, having the full power of Python at =
your fingertips makes Maki much more flexible and powerful than most =
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. =
I
have written various methods that allow me to retrieve objects that =
match
certain conditions, and each class has a method toSaxEvents(handler) =
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 =
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 =
source software, as well?
In xml documents to be processed by maki, I _could_ directly embed =
Python
code that operates on the objects and adds them to the document by =
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 =
custom
tags, and I can pass the document through a stylesheet step that =
replaces
those tags with the maki tags, then pass that output into a process =
step.
If you use a logicsheet approach like this, you can achieve a high =
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 =
PHPNuke or ezPublish. This depends strongly on the possibility to =
develop add-ons, plug-ins, modules and extensions in a easy and fast =
way. For this reason, I think that the adoption of this =
stylesheet/taglib-oriented approach is crucial for the future of Maki. =
Can I suggest you to develop a small example of such a solution? This =
would help us a lot in understanding the implementation details and in =
keeping ourselves coherent with the existing architecture.
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 =
"Portal
> system" like "Cocoon Portal" (see:
> =
http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstLook.html)=
.
> This would make much easier and faster to create Python/XML/Maki-based =
web
> sites and would allow for a wider acceptance of these technologies. =
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 =
developers really need (python-based, of course...). They do not have =
time to study a complex XML-based system, like Cocoon, and develop a =
web application from scratch. They need a full-blown, empty portal that =
they can easily install and adapt to their specific needs. That is =
exactly what PHPNuke and ezPublish give them at the moment. I will try =
to develop such a system, using Maki as a basis, as soon as I will have =
some more freetime (currently, I'm involved in a very demanding, =
security-related project. I have no time for anything else). I will keep =
you (and the other, possibly interested, people in the list) up-to-date =
about this project. If someone else is fascinated by this idea, please =
do not wait for me: I could be blocked for months...
>
> 3) Does anybody use Maki in a production environment?
So far I've only used it in a production capacity for intranets, =
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 =
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 =
Python
interfaces to libxslt continues. In the meantime, I'm using Sablotron =
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 =
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 =
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 =
case, Python-based systems seems to be faster than java-based ones, like =
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 =
what we actually need: a robust, elegant, modular system that we can use =
as a skeleton for developing a full-blown portal system like "Cocoon =
portal", PHPNuke, ezPublish and so on. If we can leave most of the =
"general purpose" tasks (XML/XSLT management, session management, DB =
abstraction layer, etc...) to Maki, we can focus on creating =
task-specific "modules" (article publishing, poll management, calendar, =
etc...) that will eventually sum up to a real, full-featured portal =
system. That would be a really great achievement, in my opinion.
Thanks again for this gift.
Alessandro Bottoni
------=_NextPart_000_0011_01C1BA2D.DBB7B930
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>See my comments below...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>><I> Date: Tue, 19 Feb 2002 14:51:39 =
+0100<BR></I>><I> To: <A=20
href=3D"mailto:xml-sig@python.org">xml-sig@python.org</A><BR></I>><I> =
From:=20
Alessandro Bottoni <<A=20
href=3D"mailto:abottoni@quadrante.com">abottoni@quadrante.com</A>><BR>=
</I>><I>=20
Subject: [XML-SIG] Maki: great!<BR></I>><I><BR></I>><I> I just =
discovered=20
Maki (<A =
href=3D"http://maki.sourceforge.net/">http://maki.sourceforge.net/</A>), =
thanks to Nicolas<BR></I>><I> Chauvat. Please, allow me to =
congratulate Sam=20
Brauer for this very<BR></I>><I> interesting project and thank him =
for having=20
donated this high-quality<BR></I>><I> software to the public=20
domain.<BR></I><BR>Thanks for your enthusiastic comments!<BR>I'm a =
little=20
embarrassed (as I feel that the documentation, examples, =
and<BR>packaging of the=20
project are less than adequate).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Everything can be improved but I think =
you did a=20
wonderful work so far :-)<BR><BR>><I><BR></I>><I> Now, a few=20
comments:<BR></I>><I> 1) I found interesting the idea to use embedded =
Python=20
code for creating<BR></I>><I> dinamic XML pages. I think this =
solution is=20
simpler and probably faster to<BR></I>><I> process than the =
complicated XSP=20
(XML Server Pages) used by Cocoon (see:<BR></I>><I> <A=20
href=3D"http://xml.apache.org/cocoon">http://xml.apache.org/cocoon</A>) =
but I=20
would like to hear the opinion of the<BR></I>><I> other partecipants =
of this=20
list regarding this topic. Is an embedded<BR></I>><I> scripting =
language=20
better than a XML-compliant page format for creating<BR></I>><I> =
dinamic web=20
pages? How about content/logic separation? How about =
developer<BR></I>><I>=20
friendliness?<BR></I><BR>I find it to be quite developer friendly. =
You can=20
make changes and test<BR>them very quickly, and you have the full power =
of=20
Python at your disposal<BR>to produce the dynamic content.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>[Alessandro Bottoni]</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I agree completely. In particular, =
having the full=20
power of Python at your fingertips makes Maki much more flexible and =
powerful=20
than most PHP-based systems.<BR><BR>Regarding content and logic =
separation, you=20
can make them quite separate<BR>by writing logicsheets (or "taglibs") =
that are=20
specific to your project.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Great! That is exactly what I hoped to =
hear from=20
you!<BR><BR>For example, on a project I am working on now I have a=20
database<BR>abstraction layer that maps Python objects to tables in a =
SQL=20
database. I<BR>have written various methods that allow me to =
retrieve=20
objects that match<BR>certain conditions, and each class has a method=20
toSaxEvents(handler) that<BR>writes out a representation of the object =
via SAX=20
events. (When maki<BR>evaluates objects to serialize them into an =
XML=20
document, it tries to call<BR>toSaxEvents() if the object has such a =
method,=20
otherwise it uses a<BR>default method that handles built-in Python types =
in a=20
sane manner and<BR>calls str() on objects without a toSaxEvents=20
method.)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Quite interesting... Do you plan to =
make this=20
module avalaible as open source software, as well?<BR><BR>In xml =
documents to be=20
processed by maki, I _could_ directly embed Python<BR>code that operates =
on the=20
objects and adds them to the document by running<BR>a process =
step.<BR><BR>Or I=20
can make up a set of tags that declare what objects I want =
to<BR>retrieve=20
(including a list of conditional and/or sort criteria expressed<BR>by =
multiple=20
nested tags, for example). In that case, I would write =
a<BR>logicsheet=20
(xsl stylesheet) that matches those tags and transforms them<BR>into =
maki tags=20
that execute and evaluate the Python code necessary to<BR>retrieve those =
objects. My input XML documents can then contain my =
custom<BR>tags, and I=20
can pass the document through a stylesheet step that replaces<BR>those =
tags with=20
the maki tags, then pass that output into a process step.<BR><BR>If you =
use a=20
logicsheet approach like this, you can achieve a high degree<BR>of =
content/logic=20
separation, since your input xml documents declare what<BR>content you =
want and=20
leave it up to your logicsheet to actually do the<BR>work to get the=20
content.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Maki could became the core of a future, =
full-blown=20
"portal system", like PHPNuke or ezPublish. This depends strongly on the =
possibility to develop add-ons, plug-ins, modules and extensions in a =
easy and=20
fast way. For this reason, I think that the adoption of this=20
stylesheet/taglib-oriented approach is crucial for the future of Maki. =
Can I=20
suggest you to develop a small example of such a solution? This would =
help us a=20
lot in understanding the implementation details and in keeping ourselves =
coherent with the existing architecture.<BR><BR>maki doesn't force you =
to do it=20
either way. You have the flexibility to<BR>decide what best suits =
your=20
needs.<BR><BR>In general I tried to write maki such that it would be =
flexible=20
and not<BR>force any particular style of =
usage.<BR><BR>><I><BR></I>><I> 2)=20
On the basis of Maki, it would be a very good idea to develop a=20
"Portal<BR></I>><I> system" like "Cocoon Portal" (see:<BR></I>><I> =
<A=20
href=3D"http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstLo=
ok.html">http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstL=
ook.html</A>).<BR></I>><I>=20
This would make much easier and faster to create Python/XML/Maki-based=20
web<BR></I>><I> sites and would allow for a wider acceptance of these =
technologies. Anybody<BR></I>><I> is thinking/working on such a=20
system?<BR></I><BR>That looks pretty neat. I'm sure one could =
create=20
something similar on<BR>top of maki/mod_python. I haven't thought =
about it=20
myself (and don't<BR>really have the time or immediate need =
to).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I think that a system like "Cocoon =
portal" is what=20
the real-world web developers really need (python-based, of course...). =
They do=20
not have time to study a complex XML-based system, like Cocoon, and =
develop a=20
web application from scratch. They need a full-blown, empty portal that =
they can=20
easily install and adapt to their specific needs. That is exactly what =
PHPNuke=20
and ezPublish give them at the moment. I</FONT><FONT face=3DArial =
size=3D2> will try=20
to develop such a system, using Maki as a basis, as soon as I will =
have=20
some more freetime (currently, I'm involved in a very demanding,=20
security-related project. I have no time for anything else). I will keep =
you=20
(and the other, possibly interested, people in the list) up-to-date =
about this=20
project. If someone else is fascinated by this idea, please do not wait =
for me:=20
I could be blocked for months...<BR><BR>><I><BR></I>><I> 3) Does =
anybody=20
use Maki in a production environment?<BR></I><BR>So far I've only used =
it in a=20
production capacity for intranets, although<BR>I'm in the process of =
creating a=20
rather large scale public site on it.<BR>Whenever that goes live (which =
won't be=20
until late summer or early fall)<BR>I'll most likely announce it on the =
maki=20
homepage.<BR><BR>><I> How about performance<BR></I>><I> and=20
stability?<BR></I><BR>maki itself seems to be quite stable if the =
software it=20
depends on<BR>(mod_python, Python, and whatever xslt extension(s) you =
use) are=20
stable<BR>and installed correctly.<BR>Similar with performance... =
If your=20
xslt processor is fast and the Python<BR>code your pages execute is =
fast, then=20
your site should perform well.<BR><BR>libxslt is the fastest xslt =
processor I've=20
used under Python so far.<BR>Unfortunately at the moment I am having =
trouble=20
trying to use it with<BR>maki. Hopefully this will clear up soon =
as=20
development on the two Python<BR>interfaces to libxslt continues. =
In the=20
meantime, I'm using Sablotron and<BR>it's pretty =
speedy.<BR><BR>Regarding speed=20
of Python code, I'm finding that trying to achieve high<BR>performance =
and at=20
the same time achieve a high separation of content and<BR>logic can be=20
tricky. Adding layers of abstraction to your code tends to<BR>make =
it=20
slower. Logicsheets can hide a lot of the complexity, but =
become<BR>rather=20
complex themselves if the code they make calls to is not=20
very<BR>abstract.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expected it: Content/Style/Logic =
separation came=20
at a cost. In any case, Python-based systems seems to be faster than =
java-based=20
ones, like Cocoon.<BR><BR>To wrap up, you are taking a risk by using =
maki (since=20
I haven't even<BR>deployed it yet on a large scale public site), but I =
hope that=20
doesn't<BR>prevent people from trying it out. It should only get =
better=20
over time.<BR></FONT><FONT face=3DArial size=3D2><BR>- Sam Brauer<BR><A=20
href=3D"http://maki.sf.net/">http://maki.sf.net/</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>[Alessandro =
Bottoni]</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I can just speak for myself but I think =
that Maki=20
is already giving us what we actually need: a robust, elegant, modular =
system=20
that we can use as a skeleton for developing a full-blown portal system =
like=20
"Cocoon portal", PHPNuke, ezPublish and so on. If we can leave most of =
the=20
"general purpose" tasks (XML/XSLT management, session management, DB =
abstraction=20
layer, etc...) to Maki, we can focus on creating task-specific "modules" =
(article publishing, poll management, calendar, etc...) that will =
eventually sum=20
up to a real, full-featured portal system. That would be a really great=20
achievement, in my opinion.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks again for this =
gift.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessandro=20
Bottoni</FONT><BR></DIV></FONT></BODY></HTML>
------=_NextPart_000_0011_01C1BA2D.DBB7B930--