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: http://wiki.apache.org/struts/HDIV ------------------------------------------------------------------------------ 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 code. + + 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 [http://www.hdiv.org/docs/api/hdiv-core/org/hdiv/dataComposer/IDataComposer.html IDataComposer] interface. + + 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. +
