[MGNLSTK-752] Login form field labels are hardcoded Created: 09/Mar/11 Updated: 10/Oct/11 Resolved: 19/Aug/11 |
|
| Status: | Closed |
| Project: | Magnolia Standard Templating Kit (closed) |
| Component/s: | paragraphs |
| Affects Version/s: | 1.4.2 |
| Fix Version/s: | 1.4.5 |
| Type: | Bug | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Christian Ringele |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Patch included: |
Yes
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
stkPURLogin.ftl is now much better (at last, I don't need to remember how the login field should be named!!), but users should still be able to customize (and translate!) the labels of the username and password fields. The submit button currently uses a resource bundle for its label, and arguably that should be editable by editors too. This form also now suffers from the same inconviences noted by Likewise, it has a formText property which is not used. It's also fairly confusing that this specific form has an "edit" button, whereas all other forms have a "edit form settings" button. |
| Comments |
| Comment by Magnolia International [ 18/Mar/11 ] |
|
Here's a patch that
|
| Comment by Magnolia International [ 22/Jun/11 ] |
|
Using the regular form dialog would also kind of help here. Not sure why there still is a stkPurForm dialog AND a stkPurLoginForm dialog. The former uses the regular form dialog and adds one tab. The latter has only 2 fields, which are not "compatible" with the patch provided here. |
| Comment by Magnolia International [ 02/Aug/11 ] |
|
The "login.infomessage" messages are a good idea, but their contents need to be reviewed: 1) the login form is not hidden in preview mode out of security reasons, but simply for consistency. 2) the line bits are most likely going to disrupt any and all layout. Worst case, you should use a <hr> tag, but I'm not even convinced about that. Not sure if we have a generic style for such "author information" (similar to the "unresolved link" case) Good job on the update task, although you should use the appropriate InstallContext to get the module's config node rather than hardcode its path in there. The Javadoc should reflect what the update does (not necessarily in detail, the code is there for that) as well as the task name/description (it doesn't need to be passed as an argument, since there is one and only usage and use-case) Lastly (pffewww), it is regrettable that the diff of the .ftl file is unreadable (the patch was!) - simply because indentation was modified so much in places unrelated to this issue. With other svn/diff tools, this can be read better (ignoring the whitespace doesn't seem to be an option on our svn-view), but it'd be good practice to keep unrelated code-style changes for separate revisions. |
| Comment by Christian Ringele [ 19/Aug/11 ] |
|
Removed the security part. Thnx, noted. Diff in Eclipse handles that quite well. But noted and will try to separate. |
| Comment by Christian Ringele [ 19/Aug/11 ] |
|
Added render test. |