Integration into PIWI
Christian Grobmeier
I am one of the guys working on PIWI:
http://code.google.com/p/piwi/
This is a web framework similar to Apache Cocoon. One can use it for
websites and write down the functionality very rapid. It has some
corners but works good already.
One of the features I miss is the continuations approach and a ORM
tool. Both seem to be in early stages available in Phaux, but I am
afraid there is less development. So, are there any plans on activly
continuing Phaux? If so, I would definitly would like to see Phaux in
some version of piwi. Since
I also would like to invite you to look at PIWI. Maybe you are more
interested in developing Phaux in the PIWI codebase. You should know
that piwi doesn't force you to use all of the functions. Together both
projects could get more attention. Finally its more fun to cooperate
:-)
Let me know - cheers
Christian
William Harford
Phuax is currently used in a commercial project with moderate usage.
It runs mobile sites for a vehicle reservation system. This system
connects to the core platform via web services. So while Phaux is not
actively developed that does not mean it is dead. It does what it does
with minimal problems. It is used and works well.
With that said its focus was never ORM. I probably should of not
included REServe with Phaux. I think Phaux is a better tool than
REServe. For the most part I have become almost totally disillusioned
with ORM. ORM, by its very nature, is a compromise and I am not sure
the low level nature of ORM is the best approach to solving the
persistence problem. I have had much better luck and cleaner design by
using services that deal specifically with persistence and core
business logic.
I am not sure Phaux and PIWI are conceptually compatible. One of
Phaux's core ideas is components. Every drawable class in Phaux is a
component. Is can be embedded, called as a dialog, or a combination of
both. While I may misunderstand your project it appears to be template
based. You could override the renderOn or renderContentOn of
WHComponent to draw the component using templates but I am not sure
that would be inline with the goals of PIWI. It might be interesting
to give it a try. How do you see the two projects as compatible? Is it
simply in the ORM component?
Component based stateful web frameworks are of huge interest to me. I
think this is a much better approach the the page based/template
approach. It provides much better reusability and cleaner design than
is possible with most other approaches. I love the approach so much I
did it again in Objective-C (http://github.com/ev0l/ESC). The
Objective-C implementation is nice because it uses code blocks giving
it a more natural callback mechanism. Using a compiled language and
Grand Central Dispatch for process handling also means it screams. In
my simple tests it can handle way more requests than Phaux/Apache.
Thanks,
Will
> --
> You received this message because you are subscribed to the Google Groups "phaux-dev" group.
> To post to this group, send email to phau...@googlegroups.com.
> To unsubscribe from this group, send email to phaux-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/phaux-dev?hl=en.
>
>
Christian Grobmeier
thanks for your long and interesting answer. I am glad to hear that
Phaux is still there.
> With that said its focus was never ORM. I probably should of not
> included REServe with Phaux. I think Phaux is a better tool than
> REServe. For the most part I have become almost totally disillusioned
> with ORM. ORM, by its very nature, is a compromise and I am not sure
> the low level nature of ORM is the best approach to solving the
> persistence problem. I have had much better luck and cleaner design by
> using services that deal specifically with persistence and core
> business logic.
I feel your pain. But sometimes ORM is giving benefits. At least there
should be one way to work with persistence in a framework. And I think
a good framework should not to force the user to use or not use such
philosophies like ORM. He should be able to decide himself. I
understood that ORM was never the focus - but the plain and less
complex approach I saw in Reserve was more to my liking as other
currently used frameworks like Propel (which is very complex for my
taste).
> I am not sure Phaux and PIWI are conceptually compatible. One of
> Phaux's core ideas is components. Every drawable class in Phaux is a
> component. Is can be embedded, called as a dialog, or a combination of
> both. While I may misunderstand your project it appears to be template
> based.
Actually, PIWI is a XML transformation framework and provide sets of
xml defintions which are transformed. You are right, that currently we
use a more template based concept at the moment. But I believe that
all the core classes are well separated and that the currently used
template based approach could exist besides other approaches. But
however, this needs to be checked.
For Phaux maybe I had a misunderstanding. I thought it would care
about the states of my form wizards and handle data states. This would
enable me to create "back" and "forward" to speak basically. To be
honest, I feel that our form processing currently works, but it has
become very complex and hard to maintain. I was the opinion that Phaux
could help here and wasn't aware that it is more a webframework. Well,
I will check it out more in detail.
> You could override the renderOn or renderContentOn of
> WHComponent to draw the component using templates but I am not sure
> that would be inline with the goals of PIWI. It might be interesting
> to give it a try. How do you see the two projects as compatible? Is it
> simply in the ORM component?
See above - if Phaux cannot be used within Form management, then its
ORM at the first glance. I need to investigate it more and deeper.
> Component based stateful web frameworks are of huge interest to me. I
> think this is a much better approach the the page based/template
> approach. It provides much better reusability and cleaner design than
> is possible with most other approaches.
Actually PIWI is very loose coupling of objects. We use some kind of
Dependency Injection (not completly, this task is on going) and lots
of reflection sometimes to decouple. At least, we get something which
we could call components too. But I think are speaking more of Wicket
approaches. However, if you have some time - I think with your likings
you
could improve piwi lots.
Cheers,
Christian