[
http://www.stripesframework.org/jira/browse/STS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Gunter resolved STS-562.
----------------------------
Resolution: Won't Fix
Fix Version/s: (was: Release 1.5.1)
I looked into this and almost committed a fix for it when I realized there's a
problem with doing this. The only way I can think of to generate an ID for an
input that is even close to unique is to identify it by some property of the
form to which it belongs -- the form's ID or action -- combined with the name
of the input. The problem is there can be more than one form on the same page
with the same action containing an input with the same name, which means the ID
would not be unique in the DOM like it should be. Because of partial forms and
AJAX requests and things like that, we can't reliably generate an ID that is
guaranteed to be unique. (I realize that random IDs aren't necessarily unique
either, but they at least cannot reliably be duplicated.)
My conclusion is that since there is a really easy way to avoid this problem
(setting an ID on the input), we should just leave this alone. I'm closing as
won't fix. Feel free to present a case for why I'm wrong.
> Use a Deterministic Technique for Generated Attributes
> ------------------------------------------------------
>
> Key: STS-562
> URL: http://www.stripesframework.org/jira/browse/STS-562
> Project: Stripes
> Issue Type: Improvement
> Components: Tag Library
> Affects Versions: Release 1.4.3
> Reporter: Walter Rumsby
> Priority: Minor
>
> We created a servlet filter to provide a shallow implementation of ETags
> similar to the one described in http://www.infoq.com/articles/etags
> When we applied this to a page that used a stripes:form with attribute
> focus="" we noticed that the filter was not working as we expected to and
> quickly realised that the issue was that the first field in the form did not
> have an explicit id attribute so Stripes was generating a random id in order
> to focus the first field in the form. This meant that the content of the
> response changed between requests and our so our ETag changed meaning a 304
> would never be sent back to the client. If the generated ids were generated
> using a deterministic approach so that they were the same for every request
> this problem would be avoided.
> A simple work around for this scenario is to explicitly set the id of the
> first field.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
