Changing the frontend framework would certainly be a major effort.
If you don't want to loose usability, whatever gets chosen as a
framework, has to provide the same tight JavaScript integration and
dynamic cofiguration options we have today. AFAIK none of the
frameworks that have been proposed
#: Boris Kraft changed the world a bit at a time by saying on 10/13/2005 9:55
PM :#
Thank you, Markus, this is really the core of it all.
On 13.10.2005, at 17:34, Markus Strickler wrote:
...
Both steps mean major efforts, binding lots of developer resources,
probably cause a lot of instabil
Thank you, Markus, this is really the core of it all.
On 13.10.2005, at 17:34, Markus Strickler wrote:
...
Both steps mean major efforts, binding lots of developer resources,
probably cause a lot of instability for the next releases (both API
wise and in terms of runtime stability, as mature,
Hi-
Thought I'd throw in my 2 cents as well. ;-)
Changing the frontend framework would certainly be a major effort.
If you don't want to loose usability, whatever gets chosen as a
framework, has to provide the same tight JavaScript integration and
dynamic cofiguration options we have today. AF
Boris Kraft wrote:
You are correct, the level of effort would be substantial, but I can
easily envision a Magnolia 3.0 release with a revised Spring-enabled
Ioc/AOP architecture that provides a truly flexible, lightweight
solution that can be deployed into any J2EE server environment and
easil
On 13.10.2005, at 00:42, Kyle Gabhart wrote:
You are correct, the level of effort would be substantial, but I can
easily envision a Magnolia 3.0 release with a revised Spring-enabled
Ioc/AOP architecture that provides a truly flexible, lightweight
solution that can be deployed into any J2EE se
Thomas Ferris Nicolaisen wrote:
Trim all your mails, darnit! :)
Sorry, will do so in the future. ;)
Using Spring (container) for Magnolia's internal architecture would
force a hge amount of refactoring (or so I can imagine), for what?
Inversion of control? JSF's backing beans provide ba
My comments inlined :-)
#: Thomas Ferris Nicolaisen changed the world a bit at a time by saying on
10/13/2005 12:19 AM :#
Trim all your mails, darnit! :)
JSF is a personal favourite of mine (being a R. Hightower fan and all), but
still, SpringMVC (a web-framework) has been very well spoken o
Trim all your mails, darnit! :)
JSF is a personal favourite of mine (being a R. Hightower fan and all), but
still, SpringMVC (a web-framework) has been very well spoken of lately. Webwork
has always been the healthiest option, while Tapestry is more simple and
web-design friendly. Don't choose
-Original Message-
From: dev-list@magnolia.info [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 12 de outubro de 2005 06:45
To: dev-list@magnolia.info
Subject: Re: [magnolia-dev] ControlSuper confusing API
#: Magnolia Dev changed the world a bit at a time by saying on 10/12/2005
10:22
EMAIL PROTECTED]
Sent: quarta-feira, 12 de outubro de 2005 06:45
To: dev-list@magnolia.info
Subject: Re: [magnolia-dev] ControlSuper confusing API
#: Magnolia Dev changed the world a bit at a time by saying on 10/12/2005
10:22 AM :#
> Philipp Bracher wrote:
>
>>>> This was ma
Philipp Bracher wrote:
- WebWork (http://www.opensymphony.com/webwork)
- Tapestry (http://jakarta.apache.org/tapestry/)
- Wicket (http://wicket.sourceforge.net/)
- JSF
Good list. If you checkout please consider:
- we use the framework only for the dialogs (controls)
- we do not replace the Entr
- WebWork (http://www.opensymphony.com/webwork)
- Tapestry (http://jakarta.apache.org/tapestry/)
- Wicket (http://wicket.sourceforge.net/)
- JSF
Good list. If you checkout please consider:
- we use the framework only for the dialogs (controls)
- we do not replace the EntryServlet (magnolia works
Wicket +1
for list details see
http://www.magnolia.info/en/magnolia/developer.html
#: Magnolia Dev changed the world a bit at a time by saying on 10/12/2005
10:22 AM :#
Philipp Bracher wrote:
This was mainly the reason to move to a better and standardized
framework.
Philipp Bracher
what do you mean by "move to a better and standardized framework"?
Is this about the plan
Philipp Bracher wrote:
This was mainly the reason to move to a better and standardized
framework.
Philipp Bracher
what do you mean by "move to a better and standardized framework"?
Is this about the plan to migrate to a component based web framework?
Yep I am.
Philipp Bracher
-
This was mainly the reason to move to a better and standardized
framework.
Philipp Bracher
what do you mean by "move to a better and standardized framework"?
Is this about the plan to migrate to a component based web framework?
Yep I am.
Philipp Bracher
#: Philipp Bracher changed the world a bit at a time by saying on 10/10/2005
7:34 PM :#
I am getting the feeling that ControlSuper API is really confusing.
The same methods are used in different context with completely
different meanings. Even if the methods names are self explanatory,
this s
I am getting the feeling that ControlSuper API is really confusing.
The same methods are used in different context with completely
different meanings. Even if the methods names are self explanatory,
this seems to be lost in the hierarchy. (take for example: name,
value).
Moreover as a base cl
Hi!
(while implementing the activation buttons support in page editor)
I am getting the feeling that ControlSuper API is really confusing. The same methods are used in
different context with completely different meanings. Even if the methods names are self
explanatory, this seems to be lost in
20 matches
Mail list logo