You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2007/03/17 18:40:04 UTC
[RT] Modernizing CForms
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom napisał(a):
>> Grzegorz Kossakowski skrev:
...
>> A modern form framework
>> =======================
>> Being a little bit provocative I'm starting to find CForms rather old
>> fashioned in style. Why so much server side stuff wouldn't it be
>> better with a form framework where most of the form framework is
>> client side and invokes REST style web services for the CRUD
>> operations on the server side resource that the form updates.
>
> Yes, you are provocative here and to be honest not really convince me
> but I think it wasn't your goal to do so. I really prefer having good,
> stable, documented and powerful form framework than new, shiny and
> fashionable form framework :-)
> I think that it must be provided a long sequence of good arguments to
> throw out one of the best Cocoon's block and start implementing new one...
[And from earlier in the thread]
>> Also we could need some "convention before configuration" and
>> "don't repeat yourself" in our forms framework. JBoss Seam
>> ( http://labs.jboss.com/portal/jbossseam/,
http://www.infoq.com/articles/jboss-seam)
>> does some cool stuff that we could imitate. Especially it uses Hibernate
>> annotations for form validation
http://docs.jboss.com/seam/1.2.0.PATCH1/reference/en/html/validation.html.
I don't propose that we should throw out the current Forms framework.
What I do propose is that it could be improved so that it would require
less work to use and so that it would support AJAX+REST style webapps
better.
Don't repeat yourself
=====================
As an alternative to using XML configurations for form definition and
binding both the form definition object and the binding object could be
configured from annotations in the model bean. With some decent set of
conventions, people who follow the conventions would be able to connect
forms to the business model with considerably less code writing. JBoss
Seam is a good example of what I have in mind.
AJAX+REST friendliness
======================
IMHO the preferred webapp architecture will move from MVC model 2
towards the kind of architecture described in figure 2 in
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
and in http://websphere.sys-con.com/read/196269.htm.
One way to support such a architectural style with our forms framework
would be to refactor it so that it allows for a more RESTish
communication style. Think about the form instance as a resource that
can have JSON (or XML) representation that you can GET, PUT, POST or
DELETE. One could also have support for letting the client ask for tthe
data types of the form for supporting client side validation.
/Daniel
Re: [RT] Modernizing CForms
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jorg Heymans napisał(a):
> Grzegorz Kossakowski wrote:
>
>> I recall some discussion about it in the past. Does it mean that even
>> we integrate Dojo into cocoon-forms very nicely user will be forced
>> to break all the modularity and use the compressor? Am I missing
>> something?
>>
>
> Aggregating and compressing [1] the required dojo modules is part of
> the build process IIUC. There is no impact on code modularity.
Actually, I was referring to the Cocoon's modularity. Compressor seems
to be not what we are talking about because it only compresses single
file by string operations. We are talking about merging many files into
one big one. This document discuss actual process:
http://redesign.dojotoolkit.org/node/19
Given that we calculate Dojo dependencies on runtime we cannot use this
tool. One solution would be special, magical pipeline component which
could take care of compiling building JS files on the fly and cache
them. I only wonder if anyone can imagine this solution simple and reliable?
Any other options?
--
Grzegorz Kossakowski
Re: [RT] Modernizing CForms
Posted by Jorg Heymans <jh...@apache.org>.
Grzegorz Kossakowski wrote:
> I recall some discussion about it in the past. Does it mean that even we
> integrate Dojo into cocoon-forms very nicely user will be forced to
> break all the modularity and use the compressor? Am I missing something?
>
Aggregating and compressing [1] the required dojo modules is part of the
build process IIUC. There is no impact on code modularity.
Jorg
[1] http://dojotoolkit.org/docs/compressor_system.html
Re: [RT] Modernizing CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Sylvain Wallez napisał(a):
>> Grzegorz Kossakowski wrote:
>>
>> The "IE gives me shudders" feeling is partly one of the reasons for Ajax
>> toolkits to exist. This unfortunately doesn't solve everything, but
>> helps a lot!
>
> This only partly address my doubts. I really ask about the prospects for
> AJAX. If I'm going to invest my time in learning AJAX toolkits I would
> like to be sure that they are capable to do much more than flashy
> examples. What's questionable for me if AJAX can become _platform_ for
> building Rich Client Applications as we already would like to use it for
> building such.
> I agree that REST is great because it's more standard way of doing
> things (HTTP-compliant) and in theory would both reduce server's load
> and improve user's experience. I also can see that this reduces a
> complexity a little bit because it's more client-server architecture and
> no viewer-(server+view producer) as it's now. However, what I'm trying
> to say is that reduced complexity on server's side does not only come
> from building REST-style applications but also from moving some
> significant part of whole complexity from the server to client.
The idea is that total complexity for a "rich" AJAX+REST application is
lower than for a "rich" MVC model 2 application. See
http://www-128.ibm.com/developerworks/java/library/wa-ajaxarch/ for a
detailed argument for this.
So for me it is quite clear that the AJAX+REST architecture is very
promising. As I just have started to explore this way I have far to less
experience of it to know if the promise holds in practice yet.
> Now it
> becomes clear that we need tools and execution platform on the client side.
> What we have now is only bunch of quite compatible and
> standard-compliant browser's and IE. There are toolkits that try to
> improve the situation but they still need to be run on IE and I fear
> that we are going to hit their limits in near future. I would like to
> see strong arguments that my doubts are just unjustified...
It is of course always hard to know with Microsoft. I actually build my
first (and this far only) Ajax widget (a lazy loading tree menu) on IE5
long before the technology was dubbed AJAX. At that time all other
browsers where far behind. Then Microsoft pulled the brake and stoped
development of IE for a long time.
Now there seem to be some reasons to hope that they take browser
development serious again. First they decided to consider browser update
security critical. So thanks to that the vast majority of users have a
modern browser now. And secondly they have given up their resistance and
have developed a cross browser Ajax framework
http://ajax.asp.net/Default.aspx which probably will make them more
motivated to make IE a good Ajax platform. But you never know about
their priorities.
> Said that, I would like to stress that I do not stop anyone from taking
> this approach and even I would be happy to help make Forms more
> REST-like. What I wouldn't like to see is a Forms client app that we are
> going to support. Haunting for IE bugs is not fun for me and I think we
> could hardly find folks that I are enthusiastic about it either.
>
>>
>>> Maybe I'm just ignorant but... is there any multi threading capability
>>> on browser side? Is it only me experiencing Firefox freezing while dojo
>>> toolkit is being loaded?
>>>
>>
>> No, JavaScript is not multi-threaded, and although there are discussions
>> IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
>> on our browsers for many years.
>
> I'm really sad and even more doubtful hearing that :/
Although JavaScript as a language doesn't contain multi threading DOM
objects like XMLHttpRequest obviously executes JS code in multiple
threads, so I'm not certain that it is such a big problem if the
language lacks such constructions.
/Daniel
Re: [RT] Modernizing CForms
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Sylvain Wallez napisał(a):
> Grzegorz Kossakowski wrote:
>
> The "IE gives me shudders" feeling is partly one of the reasons for Ajax
> toolkits to exist. This unfortunately doesn't solve everything, but
> helps a lot!
This only partly address my doubts. I really ask about the prospects for
AJAX. If I'm going to invest my time in learning AJAX toolkits I would
like to be sure that they are capable to do much more than flashy
examples. What's questionable for me if AJAX can become _platform_ for
building Rich Client Applications as we already would like to use it for
building such.
I agree that REST is great because it's more standard way of doing
things (HTTP-compliant) and in theory would both reduce server's load
and improve user's experience. I also can see that this reduces a
complexity a little bit because it's more client-server architecture and
no viewer-(server+view producer) as it's now. However, what I'm trying
to say is that reduced complexity on server's side does not only come
from building REST-style applications but also from moving some
significant part of whole complexity from the server to client. Now it
becomes clear that we need tools and execution platform on the client side.
What we have now is only bunch of quite compatible and
standard-compliant browser's and IE. There are toolkits that try to
improve the situation but they still need to be run on IE and I fear
that we are going to hit their limits in near future. I would like to
see strong arguments that my doubts are just unjustified...
Said that, I would like to stress that I do not stop anyone from taking
this approach and even I would be happy to help make Forms more
REST-like. What I wouldn't like to see is a Forms client app that we are
going to support. Haunting for IE bugs is not fun for me and I think we
could hardly find folks that I are enthusiastic about it either.
>
>> Maybe I'm just ignorant but... is there any multi threading capability
>> on browser side? Is it only me experiencing Firefox freezing while dojo
>> toolkit is being loaded?
>>
>
> No, JavaScript is not multi-threaded, and although there are discussions
> IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
> on our browsers for many years.
I'm really sad and even more doubtful hearing that :/
>
> The freezing you experience is that because you're using an uncompressed
> Dojo, and every dojo.require() potentially does a _synchronous_
> XmlHttpRequest, hence freezing the browser. The solution, that has to be
> used for any production deployment, is to use Dojo's compressor to group
> all JS files used by an application into a single compressed one. No
> more freezing in that case.
I recall some discussion about it in the past. Does it mean that even we
integrate Dojo into cocoon-forms very nicely user will be forced to
break all the modularity and use the compressor? Am I missing something?
--
Grzegorz Kossakowski
Re: [RT] Modernizing CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Grzegorz Kossakowski wrote:
> Daniel Fagerstrom napisał(a):
>
>> I don't propose that we should throw out the current Forms framework.
>> What I do propose is that it could be improved so that it would
>> require less work to use and so that it would support AJAX+REST style
>> webapps better.
>>
>> Don't repeat yourself
>> =====================
>>
>> As an alternative to using XML configurations for form definition and
>> binding both the form definition object and the binding object could
>> be configured from annotations in the model bean. With some decent set
>> of conventions, people who follow the conventions would be able to
>> connect forms to the business model with considerably less code
>> writing. JBoss Seam is a good example of what I have in mind.
>>
>
> I tend to agree with this one. I'm also supporter of less
> configuration-demanding solutions and conventions where applicable. I
> fear only if Java world (and we in particular) eventually leap from the
> "XML hell" to the "annotations hell". I can imagine this situation and
> would like to avoid it.
>
>
>> AJAX+REST friendliness
>> ======================
>>
>> IMHO the preferred webapp architecture will move from MVC model 2
>> towards the kind of architecture described in figure 2 in
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>>
>> and in http://websphere.sys-con.com/read/196269.htm.
>>
>> One way to support such a architectural style with our forms framework
>> would be to refactor it so that it allows for a more RESTish
>> communication style. Think about the form instance as a resource that
>> can have JSON (or XML) representation that you can GET, PUT, POST or
>> DELETE. One could also have support for letting the client ask for
>> tthe data types of the form for supporting client side validation.
>>
>
> I wonder where are the limits. Is it valid to treat browser as VM
> machine where we execute complicated (name them Rich) client
> applications? Although such an idea is nice, when I think of "IE" all
> the simplicity and flexibility of the solution seems to flow away to
> some nowhere land. Am I only one not so enthusiastic about AJAX
> everywhere vision?
>
The "IE gives me shudders" feeling is partly one of the reasons for Ajax
toolkits to exist. This unfortunately doesn't solve everything, but
helps a lot!
> Maybe I'm just ignorant but... is there any multi threading capability
> on browser side? Is it only me experiencing Firefox freezing while dojo
> toolkit is being loaded?
>
No, JavaScript is not multi-threaded, and although there are discussions
IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
on our browsers for many years.
The freezing you experience is that because you're using an uncompressed
Dojo, and every dojo.require() potentially does a _synchronous_
XmlHttpRequest, hence freezing the browser. The solution, that has to be
used for any production deployment, is to use Dojo's compressor to group
all JS files used by an application into a single compressed one. No
more freezing in that case.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom napisał(a):
>
> I don't propose that we should throw out the current Forms framework.
> What I do propose is that it could be improved so that it would
> require less work to use and so that it would support AJAX+REST style
> webapps better.
>
> Don't repeat yourself
> =====================
>
> As an alternative to using XML configurations for form definition and
> binding both the form definition object and the binding object could
> be configured from annotations in the model bean. With some decent set
> of conventions, people who follow the conventions would be able to
> connect forms to the business model with considerably less code
> writing. JBoss Seam is a good example of what I have in mind.
I tend to agree with this one. I'm also supporter of less
configuration-demanding solutions and conventions where applicable. I
fear only if Java world (and we in particular) eventually leap from the
"XML hell" to the "annotations hell". I can imagine this situation and
would like to avoid it.
>
> AJAX+REST friendliness
> ======================
>
> IMHO the preferred webapp architecture will move from MVC model 2
> towards the kind of architecture described in figure 2 in
> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>
> and in http://websphere.sys-con.com/read/196269.htm.
>
> One way to support such a architectural style with our forms framework
> would be to refactor it so that it allows for a more RESTish
> communication style. Think about the form instance as a resource that
> can have JSON (or XML) representation that you can GET, PUT, POST or
> DELETE. One could also have support for letting the client ask for
> tthe data types of the form for supporting client side validation.
I wonder where are the limits. Is it valid to treat browser as VM
machine where we execute complicated (name them Rich) client
applications? Although such an idea is nice, when I think of "IE" all
the simplicity and flexibility of the solution seems to flow away to
some nowhere land. Am I only one not so enthusiastic about AJAX
everywhere vision?
Maybe I'm just ignorant but... is there any multi threading capability
on browser side? Is it only me experiencing Firefox freezing while dojo
toolkit is being loaded?
--
Grzegorz Kossakowski
Re: [RT] Modernizing CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Sylvain Wallez skrev:
<snip/>
>> A very concrete example: within a Wicket application, we needed to have
>> areas of the screen be the result of the transformation of some XML
>> document. We ended up doing coding pipelines in plain Java. If Cocoon
>> had provided a simple way to use its pipeline machinery, we would have
>> used it.
>
> Although it could be even easier and most definitively should require
> less dependencies it is not that hard to use the pipeline standalone:
> http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
>
>
> For the dependencies we have done some work on splitting up Cocoon so
> that you can use just the pipeline part (see
> http://svn.apache.org/repos/asf/cocoon/trunk/core/). The main thing
> left to do is to de-Avalonize a number of core components.
Very cool!
>> All this to say that by trying to address too many concerns, Cocoon
>> dilutes the message of where its strengths are, and leads potential
>> newcomers to simply look somewhere else.
>
> We clearly need to have a more focused message. But I think that
> saying that we should not provides a webapp framework anymore but just
> some components would be to go far to long. We need to find the right
> balance.
>
>> A way to address this would be to have several subprojects in the Cocoon
>> top-level project, ensuring a greater technical separation, giving a
>> clear view of the various features the top-level project provides and
>> thus allowing people to pick-up what they need, and ultimately use more
>> and more of what this project provides.
>
> We are going in this direction. Both the cocoon-spring-configurator
> and the cocoon-servlet-service-fw (and maybe some more) are intended
> to be separate Cocoon sub projects. Lots of work left to do though.
IMO this is key for the future of Cocoon: showing that it's not (or no
more) a take-it-all-or-nothing beast, but a component statck where you
can pick up only what you need.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez skrev:
> Daniel Fagerstrom wrote:
>
>> I don't propose that we should throw out the current Forms framework.
>> What I do propose is that it could be improved so that it would
>> require less work to use and so that it would support AJAX+REST style
>> webapps better.
>>
>> Don't repeat yourself
>> =====================
>>
>> As an alternative to using XML configurations for form definition and
>> binding both the form definition object and the binding object could
>> be configured from annotations in the model bean. With some decent set
>> of conventions, people who follow the conventions would be able to
>> connect forms to the business model with considerably less code
>> writing. JBoss Seam is a good example of what I have in mind.
>>
>> AJAX+REST friendliness
>> ======================
>>
>> IMHO the preferred webapp architecture will move from MVC model 2
>> towards the kind of architecture described in figure 2 in
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>>
>> and in http://websphere.sys-con.com/read/196269.htm.
>>
>> One way to support such a architectural style with our forms framework
>> would be to refactor it so that it allows for a more RESTish
>> communication style. Think about the form instance as a resource that
>> can have JSON (or XML) representation that you can GET, PUT, POST or
>> DELETE. One could also have support for letting the client ask for
>> tthe data types of the form for supporting client side validation.
>
> I heartfully agree with these goals and it's true that CForms, more than
> old-fashioned, looks heavyweight compared to more recent solutions that
> considered partial page update and/or RPC-style interaction right from
> the beginning.
>
> Now the question that comes to mind when considering these goals is: "Is
> this still Cocoon?"
Considering the excess of ideas, languages and areas that are covered in
our repository, I'd say that Cocoon seem to be whatever at least one
comitter want it to be ;)
> So what is Cocoon:
> - an XML processing engine?
> - a REST platform (sitemap matchers)?
> - a webapp framework (flowscript, CForms)?
> - a block container for Spring components?
> - an OSGi bridge/integration platform for blocks?
>
> The still unique distinguishing features of Cocoon are the two first
> ones. When we progress in the stack, more competition and more modern
> solutions appear.
I'd say that we are in the forefront and have some unique ideas in the
"block container for Spring components" area as well. But I'm fairly biased.
For OSGi, developing bridge/integration framework is clearly better done
in other communities. But it would still be nice to apply their results
at Cocoon.
> Also, XML processing is powerful for data aggregation,
> filtering and transformation, but quickly shows its limits for business
> logic (nah, XSP+SQLTransformer is not a nice solution).
Agree.
> For RPC-style webapps, you definitely don't need Cocoon, because there's
> no need for XML anywhere. Just use Dojo/Prototype and DWR [1] connected
> to plain Java code.
Yes. Personally I'm much more attracted to AJAX+REST than AJAX+RPC, though.
> For component-based webapps with partial page
> updates, Wicket [2] is really productive. All this actually reminds me
> of some old prophecy [3].
>
> Rather than coming with its own solution for each and every aspect of
> server-side app development, the future of Cocoon is IMHO paradoxically
> in its past: XML processing engine and REST platform. By providing a
> very simple way to integrate these features in any context, it will
> allow people that use other more modern/mainstream approaches to use Cocoon.
I agree about that XML-pipeline + REST is our core offering and that it
would deserve more attention and polishing from us.
> A very concrete example: within a Wicket application, we needed to have
> areas of the screen be the result of the transformation of some XML
> document. We ended up doing coding pipelines in plain Java. If Cocoon
> had provided a simple way to use its pipeline machinery, we would have
> used it.
Although it could be even easier and most definitively should require
less dependencies it is not that hard to use the pipeline standalone:
http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
For the dependencies we have done some work on splitting up Cocoon so
that you can use just the pipeline part (see
http://svn.apache.org/repos/asf/cocoon/trunk/core/). The main thing left
to do is to de-Avalonize a number of core components.
> All this to say that by trying to address too many concerns, Cocoon
> dilutes the message of where its strengths are, and leads potential
> newcomers to simply look somewhere else.
We clearly need to have a more focused message. But I think that saying
that we should not provides a webapp framework anymore but just some
components would be to go far to long. We need to find the right balance.
> A way to address this would be to have several subprojects in the Cocoon
> top-level project, ensuring a greater technical separation, giving a
> clear view of the various features the top-level project provides and
> thus allowing people to pick-up what they need, and ultimately use more
> and more of what this project provides.
We are going in this direction. Both the cocoon-spring-configurator and
the cocoon-servlet-service-fw (and maybe some more) are intended to be
separate Cocoon sub projects. Lots of work left to do though.
> And also providing bridges to
> the other mainstream solutions rather than trying to embrace them, thus
> giving mindshare to Cocoon in other communities.
Exactly.
/Daniel
Re: [RT] Modernizing CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> I don't propose that we should throw out the current Forms framework.
> What I do propose is that it could be improved so that it would
> require less work to use and so that it would support AJAX+REST style
> webapps better.
>
> Don't repeat yourself
> =====================
>
> As an alternative to using XML configurations for form definition and
> binding both the form definition object and the binding object could
> be configured from annotations in the model bean. With some decent set
> of conventions, people who follow the conventions would be able to
> connect forms to the business model with considerably less code
> writing. JBoss Seam is a good example of what I have in mind.
>
> AJAX+REST friendliness
> ======================
>
> IMHO the preferred webapp architecture will move from MVC model 2
> towards the kind of architecture described in figure 2 in
> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>
> and in http://websphere.sys-con.com/read/196269.htm.
>
> One way to support such a architectural style with our forms framework
> would be to refactor it so that it allows for a more RESTish
> communication style. Think about the form instance as a resource that
> can have JSON (or XML) representation that you can GET, PUT, POST or
> DELETE. One could also have support for letting the client ask for
> tthe data types of the form for supporting client side validation.
I heartfully agree with these goals and it's true that CForms, more than
old-fashioned, looks heavyweight compared to more recent solutions that
considered partial page update and/or RPC-style interaction right from
the beginning.
Now the question that comes to mind when considering these goals is: "Is
this still Cocoon?"
So what is Cocoon:
- an XML processing engine?
- a REST platform (sitemap matchers)?
- a webapp framework (flowscript, CForms)?
- a block container for Spring components?
- an OSGi bridge/integration platform for blocks?
The still unique distinguishing features of Cocoon are the two first
ones. When we progress in the stack, more competition and more modern
solutions appear. Also, XML processing is powerful for data aggregation,
filtering and transformation, but quickly shows its limits for business
logic (nah, XSP+SQLTransformer is not a nice solution).
For RPC-style webapps, you definitely don't need Cocoon, because there's
no need for XML anywhere. Just use Dojo/Prototype and DWR [1] connected
to plain Java code. For component-based webapps with partial page
updates, Wicket [2] is really productive. All this actually reminds me
of some old prophecy [3].
Rather than coming with its own solution for each and every aspect of
server-side app development, the future of Cocoon is IMHO paradoxically
in its past: XML processing engine and REST platform. By providing a
very simple way to integrate these features in any context, it will
allow people that use other more modern/mainstream approaches to use Cocoon.
A very concrete example: within a Wicket application, we needed to have
areas of the screen be the result of the transformation of some XML
document. We ended up doing coding pipelines in plain Java. If Cocoon
had provided a simple way to use its pipeline machinery, we would have
used it.
All this to say that by trying to address too many concerns, Cocoon
dilutes the message of where its strengths are, and leads potential
newcomers to simply look somewhere else.
A way to address this would be to have several subprojects in the Cocoon
top-level project, ensuring a greater technical separation, giving a
clear view of the various features the top-level project provides and
thus allowing people to pick-up what they need, and ultimately use more
and more of what this project provides. And also providing bridges to
the other mainstream solutions rather than trying to embrace them, thus
giving mindshare to Cocoon in other communities.
Sylvain
[1] http://getahead.org/dwr
[2] http://incubator.apache.org/wicket/
[3] http://thread.gmane.org/gmane.text.xml.cocoon.devel/55131
--
Sylvain Wallez - http://bluxte.net