You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Sohaib Akhtar <so...@gmail.com> on 2006/02/02 06:27:56 UTC

Need Help : Comparison of open source Frameworks

Hi.

I am doing research study on open source frameworks. One of its requirements
is to provide comparison analysis that which framework support which feature
(These are the feature, which could be used for selection of framework).
Because I have not worked on these framework, so I need any of you to help
me out and please fill in the below matrix. You only have to respond in
scale of 1-3.

1 = No Support
2 = Partial Support (Either through some 3rd party tool or little support)
3 = Full Support

You can only fill in the framework you have worked on.

Thanks in Advance for your support.

Comparison



*Feature*

*Struts*

*Turbine*

*Tapestry*

*WebWork*

*Velocity*

*JSF*

   1. Provide Designer/developer separation?













   1. Can be Coupled easily with Organization Code?













   1. Built-in Internationalization (I18N) Support?













   1. Provide built-in Security framework?













   1. Provide Validation and conversion support?













   1. Can Manage Component State?













   1. Support new Component's development?













   1. Provide built-in Standard components?













   1. Provide User documentation?













   1. Provide Error handling support?













   1. Built-in Testability?













   1. Increase Developer productivity?













   1. Have IDE/tool support?













   1. Is easy to learn?













   1. Is Extensible?













   1. Free Licensing?













   1. Which programming language is supported?













   1. Support Integration with other technologies?















Appendix:

*Features Definition*

1 Designer/developer separation This attribute will help us in identifying
the extent to which framework supports the separation of different roles


2 Coupling Whenever choosing an application framework, it is important to
recognize that the framework might be outgrown.  Regardless of the reason,
if there is a clear separation (loose coupling) of the framework's code and
the organization's code, it will be a fairly painless migration from the
original framework to a new framework


3 Internationalization (I18N) A web application framework must provide
support for internationalization to allow for web applications to be
localized because framework support for internationalization (I18N) can save
a considerable amount of development time and effort in handling items like
character encoding and addressing locale-specific requirements


4 Security The framework selected should have support for your
organization's security infrastructure.  However, the framework might also
provide additional security functionality that can be very useful to the
organization.


5 Validation and conversion An essential feature of any web application
framework is strong support for validation. Type conversion is a closely
related task, in the sense that successful type conversion is often a
precondition to successful validation of an inputted value.


6 Component state management Another important feature for any framework is
how well it manages the state of the components. These days most of the
frameworks support the state management of component and it leads to less
development time and cost.


7 Component development In spite of the variety of existing components
available, it probably won't be long before you find the need (or urge) to
create your own components. How successful, enjoyable and productive this
process is depends on the component development model of the framework
you're using.


8 Standard components The standard components are the well documented, out
of the box components that you get for free. They are the components that
you can confidently expect to be ported to future versions of the framework.
Most of the frameworks provide a set of standard components. By restricting
yourself to using standard components, you can avoid vendor lock-in,
component compatibility issues and license costs.


9 User documentation Reviewing documentation and sample applications will
probably reveal the framework architect's expectations and intentions as to
how exceptions should be handled.


10 Error handling The framework might favor or accommodate certain ways of
handling errors than other error-handling methods.  For example, it might be
more appropriate to pass exceptions up the hierarchy if the framework uses
declarative programming for handling errors rather than trying to handle the
exception where it took place.


11 Testability An increasingly important requirement for web applications is
that they can be easily unit tested. The testability of an application
depends directly on how free your application code is from framework
specific dependencies.


12 Developer productivity Frameworks are very productive compared to
traditional MVC frameworks largely because they allow you to write
applications with less code. How they measure up against each other also
depends on how efficiently this code can be created and modified, and how
easily and quickly errors can be detected and corrected.


13 IDE/tool support Development tools such as IDE's are tremendous
time-savers for developers.  Similarly, organizations tend to adopt and have
the infrastructure in place for a particular Version Control Systems
(example, PVCS).  A certain amount of testing of the framework and these
tools during a trial period might be necessary to make sure that they can be
integrated.


14 Ease of learning In the same way that powerful features and the promise
of greater productivity in the future will draw developers to a framework,
the perception that a framework is complex or hard to learn will put many
off.


15 Extensibility The extensibility of a framework is how easily you can
replace or add to the parts of the framework that don't meet your needs,
without affecting other parts of the framework.


16 Licensing Licensing of a framework is also very important aspect while
selecting a framework because open sources are not always available for
free, they have licensing costs. So one should consider the licensing
options before selecting any framework.


17 Language requirement Frameworks tend to target a specific programming
language.  If your organization has settled on a particular programming
language, the language and platform will be two of the major criteria in
determining what frameworks are available to you.


18 Integration with other technologies When we talk about the open source
web frameworks then one should consider the availability of long list of
other open source technologies and a framework should be able to work along
with those technologies e.g. hibernate. It could save lot of re-work and
cost. Moreover integration with Enterprise Java Beans, Web Services
Object/Relational tools, XML-RPC consumption and WAP/WML device/browser
support is very critical while deciding framework for an application.


Thanks again,

Sohaib

Re: Need Help : Comparison of open source Frameworks

Posted by Leandro Saad <le...@gmail.com>.
Hi Sohaib; Just a note: velocity and JSF are not application frameworks. I
see them more like libraries. They are not designed to handle most problems
that web application developers must face.

I'm sending the answers for  guara <http://guara-framework.sf.net> .

Cheers!


On 2/2/06, Sohaib Akhtar <so...@gmail.com> wrote:
>
> Hi.
>
> I am doing research study on open source frameworks. One of its
> requirements
> is to provide comparison analysis that which framework support which
> feature
> (These are the feature, which could be used for selection of framework).
> Because I have not worked on these framework, so I need any of you to help
> me out and please fill in the below matrix. You only have to respond in
> scale of 1-3.
>
> 1 = No Support
> 2 = Partial Support (Either through some 3rd party tool or little support)
> 3 = Full Support
>
> You can only fill in the framework you have worked on.
>
> Thanks in Advance for your support.
>
> Comparison
>
>
>    1. Provide Designer/developer separation?


3. The designer must know the template language of choice (velocity,
freemarker, etc)

   1. Can be Coupled easily with Organization Code?


3. Business logic are implemented in Modules which implement the Module
interface. The module execution is configurable using xml.


   1. Built-in Internationalization (I18N) Support?



2. Through 3rd party components

   1. Provide built-in Security framework?


 2. Through 3rd party components

   1. Provide Validation and conversion support?


2. Through 3rd party components.

   1. Can Manage Component State?


3. Guara uses pulga, a small avalon container implementation, for its
internal structure. The same container may be used to control Components
state/lifecycle

   1. Support new Component's development?


3.  Guara  uses  avalon-framework as its internal component model. If you
don't like the way a components works, you can replace it easily.

   1. Provide built-in Standard components?


2.

   1. Provide User documentation?


2.

   1. Provide Error handling support?


3.

   1. Built-in Testability?


2.

   1. Increase Developer productivity?


3. Guara has builtin integration with ajax. You are able to execute the
exact same business logic (Module) via a normal request or ajax.

   1. Have IDE/tool support?


1.

   1. Is easy to learn?


3. Guara tries to be a small and simple framework. Very easy to learn.

   1. Is Extensible?


3. Guara uses the avalon component model internally. Its very easy to extend
if you need. The processing logic is configurable/extensible too. All
requests are processed by a configurable pipeline using xml. You can
add/remove/change steps if you want. This enables easy ajax integration too.

   1. Free Licensing?


3. ASF

   1. Which programming language is supported?


3. Java

   1. Support Integration with other technologies?


3. Since Guara is minimal you can choose you OR mapping framework, template
engine, etc


--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Technologies
sitedafesta.com.br
db.apache.org/ojb
guara-framework.sf.net
xingu.sf.net

Re: Need Help : Comparison of open source Frameworks

Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Shoaib,

+) I assume you talk about web application frameworks?!
+) Velocity is definitely not a contender - nothing wrong with Velocity (I love it) but it is a template engine
+) depending on your definition of web application framework Struts and to a lesser degree JSF might share the same fate as Velocity
+) I don't know the scope of your work but you might have missed Cocoon and/or Spring

Cheers,

Siegfried Goeschl


David Demner wrote:

>Hi Shoaib,
>
>I will try to answer your questions.  Please let me know if you need more
>detail.
>
>Looking at my answers, I seem like a bit of a zealot, but the questions you
>are asking are really playing to Turbine's strengths (great basic
>components, but the ability to easily replace functionality with other
>components - custom or 3rd party).  
>
>Thanks,
>
>David
>
>-----Original Message-----
>From: Sohaib Akhtar [mailto:sohaibakhtar@gmail.com] 
>Sent: February 1, 2006 9:28 PM
>To: turbine-dev@jakarta.apache.org
>Subject: Need Help : Comparison of open source Frameworks
>
>Hi.
>
>I am doing research study on open source frameworks. One of its requirements
>is to provide comparison analysis that which framework support which feature
>(These are the feature, which could be used for selection of framework).
>Because I have not worked on these framework, so I need any of you to help
>me out and please fill in the below matrix. You only have to respond in
>scale of 1-3.
>
>1 = No Support
>2 = Partial Support (Either through some 3rd party tool or little support)
>3 = Full Support
>
>You can only fill in the framework you have worked on.
>
>Thanks in Advance for your support.
>
>Comparison
>
>
>
>*Feature*
>
>*Struts*
>
>*Turbine*
>
>*Tapestry*
>
>*WebWork*
>
>*Velocity*
>
>*JSF*
>
>   1. Provide Designer/developer separation?
>
>3 - Turbine is built around the MVC design pattern - see
>http://jakarta.apache.org/turbine/further-reading/model2+1.html for more
>details.
>
>
>
>
>
>
>
>
>
>
>
>   1. Can be Coupled easily with Organization Code?
>
>3 - I'm not sure what you mean by Organization Code, but it can be coupled
>easily with external code (at all 3 levels).
>
>
>
>
>
>
>
>
>
>
>
>   1. Built-in Internationalization (I18N) Support?
>
>3 - Yes, although some people have struggled a little with it.
>
>
>
>
>
>
>
>
>
>
>
>   1. Provide built-in Security framework?
>
>3 - It contains a good one that is fully functional, but it's easy to use a
>third-party one if you need more features.
>
>
>
>
>
>
>
>
>
>
>
>   1. Provide Validation and conversion support?
>
>3 - It contains a good one that is fully functional, but it's easy to use a
>third-party one if you need more features.
>
>
>
>
>
>
>
>
>
>
>
>   1. Can Manage Component State?
>
>3
>
>
>
>
>
>
>
>
>
>
>
>   1. Support new Component's development?
>
>3
>
>
>
>
>
>
>
>
>
>
>
>   1. Provide built-in Standard components?
>
>
>3
>
>
>
>
>
>
>
>
>
>
>   1. Provide User documentation?
>
>
>3
>
>
>
>
>
>
>
>
>
>
>   1. Provide Error handling support?
>
>3
>
>
>
>
>
>
>
>
>
>
>
>   1. Built-in Testability?
>
>
>3
>
>
>
>
>
>
>
>
>
>
>   1. Increase Developer productivity?
>
>
>3
>
>
>
>
>
>
>
>
>
>
>   1. Have IDE/tool support?
>
>3 - This is a little misleading.  The Turbine project spawned Maven (and
>many other now-jakarta projects like Torque) but most of this has been
>decoupled now.  Also the IDE question isn't very appropriate - turbine is
>easy enough that you only really need to edit one configuration file.  The
>technologies that are being used (Velocity, Hibernate, etc) have decent IDE
>support.
>
>
>
>
>
>
>
>
>
>
>
>   1. Is easy to learn?
>
>3 - There are sample applications and good user documentation.
>
>
>
>
>
>
>
>
>
>
>
>   1. Is Extensible?
>
>
>3 - Turbine is built around the ability to replace itself with third-party
>components, and this will be further accentuated in the current development
>version.
>
>
>
>
>
>
>
>
>
>
>   1. Free Licensing?
>
>3
>
>
>
>
>
>
>
>
>
>
>
>   1. Which programming language is supported?
>
>
>Java
>
>
>
>
>
>
>
>
>
>
>   1. Support Integration with other technologies?
>
>
>See the "Extensible" section.
>
>
>
>
>
>
>
>
>
>
>
>
>Appendix:
>
>*Features Definition*
>
>1 Designer/developer separation This attribute will help us in identifying
>the extent to which framework supports the separation of different roles
>
>
>2 Coupling Whenever choosing an application framework, it is important to
>recognize that the framework might be outgrown.  Regardless of the reason,
>if there is a clear separation (loose coupling) of the framework's code and
>the organization's code, it will be a fairly painless migration from the
>original framework to a new framework
>
>
>3 Internationalization (I18N) A web application framework must provide
>support for internationalization to allow for web applications to be
>localized because framework support for internationalization (I18N) can save
>a considerable amount of development time and effort in handling items like
>character encoding and addressing locale-specific requirements
>
>
>4 Security The framework selected should have support for your
>organization's security infrastructure.  However, the framework might also
>provide additional security functionality that can be very useful to the
>organization.
>
>
>5 Validation and conversion An essential feature of any web application
>framework is strong support for validation. Type conversion is a closely
>related task, in the sense that successful type conversion is often a
>precondition to successful validation of an inputted value.
>
>
>6 Component state management Another important feature for any framework is
>how well it manages the state of the components. These days most of the
>frameworks support the state management of component and it leads to less
>development time and cost.
>
>
>7 Component development In spite of the variety of existing components
>available, it probably won't be long before you find the need (or urge) to
>create your own components. How successful, enjoyable and productive this
>process is depends on the component development model of the framework
>you're using.
>
>
>8 Standard components The standard components are the well documented, out
>of the box components that you get for free. They are the components that
>you can confidently expect to be ported to future versions of the framework.
>Most of the frameworks provide a set of standard components. By restricting
>yourself to using standard components, you can avoid vendor lock-in,
>component compatibility issues and license costs.
>
>
>9 User documentation Reviewing documentation and sample applications will
>probably reveal the framework architect's expectations and intentions as to
>how exceptions should be handled.
>
>
>10 Error handling The framework might favor or accommodate certain ways of
>handling errors than other error-handling methods.  For example, it might be
>more appropriate to pass exceptions up the hierarchy if the framework uses
>declarative programming for handling errors rather than trying to handle the
>exception where it took place.
>
>
>11 Testability An increasingly important requirement for web applications is
>that they can be easily unit tested. The testability of an application
>depends directly on how free your application code is from framework
>specific dependencies.
>
>
>12 Developer productivity Frameworks are very productive compared to
>traditional MVC frameworks largely because they allow you to write
>applications with less code. How they measure up against each other also
>depends on how efficiently this code can be created and modified, and how
>easily and quickly errors can be detected and corrected.
>
>
>13 IDE/tool support Development tools such as IDE's are tremendous
>time-savers for developers.  Similarly, organizations tend to adopt and have
>the infrastructure in place for a particular Version Control Systems
>(example, PVCS).  A certain amount of testing of the framework and these
>tools during a trial period might be necessary to make sure that they can be
>integrated.
>
>
>14 Ease of learning In the same way that powerful features and the promise
>of greater productivity in the future will draw developers to a framework,
>the perception that a framework is complex or hard to learn will put many
>off.
>
>
>15 Extensibility The extensibility of a framework is how easily you can
>replace or add to the parts of the framework that don't meet your needs,
>without affecting other parts of the framework.
>
>
>16 Licensing Licensing of a framework is also very important aspect while
>selecting a framework because open sources are not always available for
>free, they have licensing costs. So one should consider the licensing
>options before selecting any framework.
>
>
>17 Language requirement Frameworks tend to target a specific programming
>language.  If your organization has settled on a particular programming
>language, the language and platform will be two of the major criteria in
>determining what frameworks are available to you.
>
>
>18 Integration with other technologies When we talk about the open source
>web frameworks then one should consider the availability of long list of
>other open source technologies and a framework should be able to work along
>with those technologies e.g. hibernate. It could save lot of re-work and
>cost. Moreover integration with Enterprise Java Beans, Web Services
>Object/Relational tools, XML-RPC consumption and WAP/WML device/browser
>support is very critical while deciding framework for an application.
>
>
>Thanks again,
>
>Sohaib
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org


RE: Need Help : Comparison of open source Frameworks

Posted by David Demner <tu...@demner.com>.
Hi Shoaib,

I will try to answer your questions.  Please let me know if you need more
detail.

Looking at my answers, I seem like a bit of a zealot, but the questions you
are asking are really playing to Turbine's strengths (great basic
components, but the ability to easily replace functionality with other
components - custom or 3rd party).  

Thanks,

David

-----Original Message-----
From: Sohaib Akhtar [mailto:sohaibakhtar@gmail.com] 
Sent: February 1, 2006 9:28 PM
To: turbine-dev@jakarta.apache.org
Subject: Need Help : Comparison of open source Frameworks

Hi.

I am doing research study on open source frameworks. One of its requirements
is to provide comparison analysis that which framework support which feature
(These are the feature, which could be used for selection of framework).
Because I have not worked on these framework, so I need any of you to help
me out and please fill in the below matrix. You only have to respond in
scale of 1-3.

1 = No Support
2 = Partial Support (Either through some 3rd party tool or little support)
3 = Full Support

You can only fill in the framework you have worked on.

Thanks in Advance for your support.

Comparison



*Feature*

*Struts*

*Turbine*

*Tapestry*

*WebWork*

*Velocity*

*JSF*

   1. Provide Designer/developer separation?

3 - Turbine is built around the MVC design pattern - see
http://jakarta.apache.org/turbine/further-reading/model2+1.html for more
details.











   1. Can be Coupled easily with Organization Code?

3 - I'm not sure what you mean by Organization Code, but it can be coupled
easily with external code (at all 3 levels).











   1. Built-in Internationalization (I18N) Support?

3 - Yes, although some people have struggled a little with it.











   1. Provide built-in Security framework?

3 - It contains a good one that is fully functional, but it's easy to use a
third-party one if you need more features.











   1. Provide Validation and conversion support?

3 - It contains a good one that is fully functional, but it's easy to use a
third-party one if you need more features.











   1. Can Manage Component State?

3











   1. Support new Component's development?

3











   1. Provide built-in Standard components?


3










   1. Provide User documentation?


3










   1. Provide Error handling support?

3











   1. Built-in Testability?


3










   1. Increase Developer productivity?


3










   1. Have IDE/tool support?

3 - This is a little misleading.  The Turbine project spawned Maven (and
many other now-jakarta projects like Torque) but most of this has been
decoupled now.  Also the IDE question isn't very appropriate - turbine is
easy enough that you only really need to edit one configuration file.  The
technologies that are being used (Velocity, Hibernate, etc) have decent IDE
support.











   1. Is easy to learn?

3 - There are sample applications and good user documentation.











   1. Is Extensible?


3 - Turbine is built around the ability to replace itself with third-party
components, and this will be further accentuated in the current development
version.










   1. Free Licensing?

3











   1. Which programming language is supported?


Java










   1. Support Integration with other technologies?


See the "Extensible" section.












Appendix:

*Features Definition*

1 Designer/developer separation This attribute will help us in identifying
the extent to which framework supports the separation of different roles


2 Coupling Whenever choosing an application framework, it is important to
recognize that the framework might be outgrown.  Regardless of the reason,
if there is a clear separation (loose coupling) of the framework's code and
the organization's code, it will be a fairly painless migration from the
original framework to a new framework


3 Internationalization (I18N) A web application framework must provide
support for internationalization to allow for web applications to be
localized because framework support for internationalization (I18N) can save
a considerable amount of development time and effort in handling items like
character encoding and addressing locale-specific requirements


4 Security The framework selected should have support for your
organization's security infrastructure.  However, the framework might also
provide additional security functionality that can be very useful to the
organization.


5 Validation and conversion An essential feature of any web application
framework is strong support for validation. Type conversion is a closely
related task, in the sense that successful type conversion is often a
precondition to successful validation of an inputted value.


6 Component state management Another important feature for any framework is
how well it manages the state of the components. These days most of the
frameworks support the state management of component and it leads to less
development time and cost.


7 Component development In spite of the variety of existing components
available, it probably won't be long before you find the need (or urge) to
create your own components. How successful, enjoyable and productive this
process is depends on the component development model of the framework
you're using.


8 Standard components The standard components are the well documented, out
of the box components that you get for free. They are the components that
you can confidently expect to be ported to future versions of the framework.
Most of the frameworks provide a set of standard components. By restricting
yourself to using standard components, you can avoid vendor lock-in,
component compatibility issues and license costs.


9 User documentation Reviewing documentation and sample applications will
probably reveal the framework architect's expectations and intentions as to
how exceptions should be handled.


10 Error handling The framework might favor or accommodate certain ways of
handling errors than other error-handling methods.  For example, it might be
more appropriate to pass exceptions up the hierarchy if the framework uses
declarative programming for handling errors rather than trying to handle the
exception where it took place.


11 Testability An increasingly important requirement for web applications is
that they can be easily unit tested. The testability of an application
depends directly on how free your application code is from framework
specific dependencies.


12 Developer productivity Frameworks are very productive compared to
traditional MVC frameworks largely because they allow you to write
applications with less code. How they measure up against each other also
depends on how efficiently this code can be created and modified, and how
easily and quickly errors can be detected and corrected.


13 IDE/tool support Development tools such as IDE's are tremendous
time-savers for developers.  Similarly, organizations tend to adopt and have
the infrastructure in place for a particular Version Control Systems
(example, PVCS).  A certain amount of testing of the framework and these
tools during a trial period might be necessary to make sure that they can be
integrated.


14 Ease of learning In the same way that powerful features and the promise
of greater productivity in the future will draw developers to a framework,
the perception that a framework is complex or hard to learn will put many
off.


15 Extensibility The extensibility of a framework is how easily you can
replace or add to the parts of the framework that don't meet your needs,
without affecting other parts of the framework.


16 Licensing Licensing of a framework is also very important aspect while
selecting a framework because open sources are not always available for
free, they have licensing costs. So one should consider the licensing
options before selecting any framework.


17 Language requirement Frameworks tend to target a specific programming
language.  If your organization has settled on a particular programming
language, the language and platform will be two of the major criteria in
determining what frameworks are available to you.


18 Integration with other technologies When we talk about the open source
web frameworks then one should consider the availability of long list of
other open source technologies and a framework should be able to work along
with those technologies e.g. hibernate. It could save lot of re-work and
cost. Moreover integration with Enterprise Java Beans, Web Services
Object/Relational tools, XML-RPC consumption and WAP/WML device/browser
support is very critical while deciding framework for an application.


Thanks again,

Sohaib


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org


RE: Need Help : Comparison of open source Frameworks

Posted by David Demner <tu...@demner.com>.
Hi Shoaib,

I will try to answer your questions.  Please let me know if you need more
detail.

Looking at my answers, I seem like a bit of a zealot, but the questions you
are asking are really playing to Turbine's strengths (great basic
components, but the ability to easily replace functionality with other
components - custom or 3rd party).  

Thanks,

David

-----Original Message-----
From: Sohaib Akhtar [mailto:sohaibakhtar@gmail.com] 
Sent: February 1, 2006 9:28 PM
To: turbine-dev@jakarta.apache.org
Subject: Need Help : Comparison of open source Frameworks

Hi.

I am doing research study on open source frameworks. One of its requirements
is to provide comparison analysis that which framework support which feature
(These are the feature, which could be used for selection of framework).
Because I have not worked on these framework, so I need any of you to help
me out and please fill in the below matrix. You only have to respond in
scale of 1-3.

1 = No Support
2 = Partial Support (Either through some 3rd party tool or little support)
3 = Full Support

You can only fill in the framework you have worked on.

Thanks in Advance for your support.

Comparison



*Feature*

*Struts*

*Turbine*

*Tapestry*

*WebWork*

*Velocity*

*JSF*

   1. Provide Designer/developer separation?

3 - Turbine is built around the MVC design pattern - see
http://jakarta.apache.org/turbine/further-reading/model2+1.html for more
details.











   1. Can be Coupled easily with Organization Code?

3 - I'm not sure what you mean by Organization Code, but it can be coupled
easily with external code (at all 3 levels).











   1. Built-in Internationalization (I18N) Support?

3 - Yes, although some people have struggled a little with it.











   1. Provide built-in Security framework?

3 - It contains a good one that is fully functional, but it's easy to use a
third-party one if you need more features.











   1. Provide Validation and conversion support?

3 - It contains a good one that is fully functional, but it's easy to use a
third-party one if you need more features.











   1. Can Manage Component State?

3











   1. Support new Component's development?

3











   1. Provide built-in Standard components?


3










   1. Provide User documentation?


3










   1. Provide Error handling support?

3











   1. Built-in Testability?


3










   1. Increase Developer productivity?


3










   1. Have IDE/tool support?

3 - This is a little misleading.  The Turbine project spawned Maven (and
many other now-jakarta projects like Torque) but most of this has been
decoupled now.  Also the IDE question isn't very appropriate - turbine is
easy enough that you only really need to edit one configuration file.  The
technologies that are being used (Velocity, Hibernate, etc) have decent IDE
support.











   1. Is easy to learn?

3 - There are sample applications and good user documentation.











   1. Is Extensible?


3 - Turbine is built around the ability to replace itself with third-party
components, and this will be further accentuated in the current development
version.










   1. Free Licensing?

3











   1. Which programming language is supported?


Java










   1. Support Integration with other technologies?


See the "Extensible" section.












Appendix:

*Features Definition*

1 Designer/developer separation This attribute will help us in identifying
the extent to which framework supports the separation of different roles


2 Coupling Whenever choosing an application framework, it is important to
recognize that the framework might be outgrown.  Regardless of the reason,
if there is a clear separation (loose coupling) of the framework's code and
the organization's code, it will be a fairly painless migration from the
original framework to a new framework


3 Internationalization (I18N) A web application framework must provide
support for internationalization to allow for web applications to be
localized because framework support for internationalization (I18N) can save
a considerable amount of development time and effort in handling items like
character encoding and addressing locale-specific requirements


4 Security The framework selected should have support for your
organization's security infrastructure.  However, the framework might also
provide additional security functionality that can be very useful to the
organization.


5 Validation and conversion An essential feature of any web application
framework is strong support for validation. Type conversion is a closely
related task, in the sense that successful type conversion is often a
precondition to successful validation of an inputted value.


6 Component state management Another important feature for any framework is
how well it manages the state of the components. These days most of the
frameworks support the state management of component and it leads to less
development time and cost.


7 Component development In spite of the variety of existing components
available, it probably won't be long before you find the need (or urge) to
create your own components. How successful, enjoyable and productive this
process is depends on the component development model of the framework
you're using.


8 Standard components The standard components are the well documented, out
of the box components that you get for free. They are the components that
you can confidently expect to be ported to future versions of the framework.
Most of the frameworks provide a set of standard components. By restricting
yourself to using standard components, you can avoid vendor lock-in,
component compatibility issues and license costs.


9 User documentation Reviewing documentation and sample applications will
probably reveal the framework architect's expectations and intentions as to
how exceptions should be handled.


10 Error handling The framework might favor or accommodate certain ways of
handling errors than other error-handling methods.  For example, it might be
more appropriate to pass exceptions up the hierarchy if the framework uses
declarative programming for handling errors rather than trying to handle the
exception where it took place.


11 Testability An increasingly important requirement for web applications is
that they can be easily unit tested. The testability of an application
depends directly on how free your application code is from framework
specific dependencies.


12 Developer productivity Frameworks are very productive compared to
traditional MVC frameworks largely because they allow you to write
applications with less code. How they measure up against each other also
depends on how efficiently this code can be created and modified, and how
easily and quickly errors can be detected and corrected.


13 IDE/tool support Development tools such as IDE's are tremendous
time-savers for developers.  Similarly, organizations tend to adopt and have
the infrastructure in place for a particular Version Control Systems
(example, PVCS).  A certain amount of testing of the framework and these
tools during a trial period might be necessary to make sure that they can be
integrated.


14 Ease of learning In the same way that powerful features and the promise
of greater productivity in the future will draw developers to a framework,
the perception that a framework is complex or hard to learn will put many
off.


15 Extensibility The extensibility of a framework is how easily you can
replace or add to the parts of the framework that don't meet your needs,
without affecting other parts of the framework.


16 Licensing Licensing of a framework is also very important aspect while
selecting a framework because open sources are not always available for
free, they have licensing costs. So one should consider the licensing
options before selecting any framework.


17 Language requirement Frameworks tend to target a specific programming
language.  If your organization has settled on a particular programming
language, the language and platform will be two of the major criteria in
determining what frameworks are available to you.


18 Integration with other technologies When we talk about the open source
web frameworks then one should consider the availability of long list of
other open source technologies and a framework should be able to work along
with those technologies e.g. hibernate. It could save lot of re-work and
cost. Moreover integration with Enterprise Java Beans, Web Services
Object/Relational tools, XML-RPC consumption and WAP/WML device/browser
support is very critical while deciding framework for an application.


Thanks again,

Sohaib


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org