struts-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Struts Wiki] Update of "HDIV" by Gorka Vicente
Date Mon, 10 Dec 2007 15:57:50 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.

The following page has been changed by Gorka Vicente:

  Also, given the list of frameworks that you already support, don't you already have an internal
API, so that the bulk of your code is common for all frameworks, and you just have a small
shim to specialise it for each framework? If that's the case, then how much value is there
in having a shared SPI just within Struts? You really need all of the frameworks to implement
that SPI, not just Struts, in order to get rid of your per-framework shims, in which case
you really want to engage all of the frameworks in the SPI design, not just the Struts team.
+ '''HDIV team:''' From our point of view, although we find interesting to define a common
interface for all the frameworks, our primary goal is to add new extension points to Struts'
API so that Struts' users can use it in a transparent way, without having to copy any source
+ The real problem is similar to what happens in Struts 1 with the RequestProcessor: when
you need to intercept a request's life cycle, many times you are forced to extend the RequestProcessor
and copy parts of the existing code next to the extension. This problem was solved in Struts2,
because each step of the life cycle is implemented by a different interceptor.
+ Actually, we want to add extension points to the HTML creation process.
+ When implementing HDIV for Struts, we had to extend tags and copy parts of the Struts' source
code in order to fulfil HDIV's objectives. For us, these are the main reasons why an interface
should be created:
+  1. Avoid having to extend tags and copy source code. Also avoids creating a new version
for the extension for each Struts' version.
+  2. Provide extension points that could be used by any framework.
+  3. Eliminate the direct dependency between Struts and HDIV.
+ If we integrate HDIV natively in the tags, without using an interface, we eliminate an extension
point that could be required by other frameworks or by Struts itself. Nowadays, we don´t
know who and how will require this interface (the automatization of the webflow's flow execution
key could be an example), but from a designer point of view it is always better to define
an interface that could change from version to version.
+ There should be two different implementations of this interface: the one provided by HDIV
and the one provided by Struts. Struts' implementation would keep the current tag behaviour
and HDIV's one would add security functionalities.
+ In our opinion, HDIV's implementation should be configured by default in order to make the
application safer. If the developers don't require HDIV they could modify the configuration
and use the empty implementation provided by Struts.
+ So, although we find using an interface a better solution, we don´t have any problem if
the final decision is to include it natively in the code.
  = Performance =
  '''Ted Husted:''' It's unusual that a feature such as this comes without penality. If HDIV
were native, what would be the performance cost? Complexity cost? 
@@ -67, +90 @@

  '''Martin Cooper:''' If I am not using any server-side presentation technology at all, which
parts of HDIV do I lose? Which can I still use?
+ '''HDIV team:''' If no presentation framework is used (or the one used is not supported
by HDIV), the only way to use HDIV is to consume the base API offered by HDIV core  (hdiv-core).
That is, the program which generates the HTML code should consume the methods offered by the
[ IDataComposer]
+ Obviously, in this case the use of HDIV is not transparent as it is when we use the extended
tags. Anyway, the validation phase made by the HDIV filter doesn't change in any case.

View raw message