- This topic has 6 replies, 4 voices, and was last updated 20 years, 10 months ago by
.
-
Posts
-
Are there any plans to update the JSP preview to render Struts tags? For example, given the following source (fragment)…
<bean:message key=”person.name” />:<html:text property=”name” />
… the preview would display a text input field preceeded by the field name as specified in the message resources.
I think this would an excellent enhancement to the Struts support. Let me know if any clarification is required.
-David
Agreed, quite a bit of work for a relatively small usability improvement. Maybe parsing out of the textfield, but even then that’s TLD-specific and doesn’t help if BEA offers something similiar in their TLDs, or Sun in their TLDs or maybe even Tapestry or other framework.
So the solution is something to what NOP said, running an internal server… in which case you might find just changing your docBase (For Tomcat) in your server’s config file to point to your dev webroot would provide you the functionality you needed; so you can just hit “refresh” in your browser and immediately see the new file.
Of course when deploying you’d want to have the deployment server configured differently 🙂
I’m basing the request from functionality found in IBM’s WSAD 5.1. Maybe if you have access to this IDE, then you would have a better idea of what I am asking for.
WSAD does not run an internal server to render all custom tags. It renderes a subset of Struts tags that represent various form fields (text, text-area, checkbox, radio button) and buttons (submit, cancel, etc). WSAD also must parse the message-resource file to decode the <bean:message…/> tag.
The real benifit to this is so that I can select an input field in the preview, then switch to the source with my cursor in the desired location. This is really helpful when working with large pages.
This is really just a ‘nice to have’ feature. The IDE is still excellent without it.
Such a solution requires much more than just “parse some messages”.
E.g.: Since MyEclipse “only” uses “some” browser to display, there is no feedback what gets clicked.
For me there is no need to support struts, they should support my taglibs 😉
NOP
I understand that this is really two or three requirements.
1) Parsing the message-resource file so that the bean:message tag can display the key’s value. I would take this feature alone.
2) Rendering a limited number of Strut’s tags. I’d be happy with text, text-area, checkbox, and radio button.
3) Finally, it really isn’t the ‘preview’ tab of the editor in WSAD that lets me select a region, then switch to the source with the cursor in the disired location. It’s the WYSIWYG tab. Probably rediculously difficult to implement, and provides little value since most people really don’t code in that mode. It’s more of a sales gimmick (imho).
Side note: As a develper, I am often put off by requirements that are difficult to implement and seem to provide little value. But sometimes (just sometimes), I find myself using those stupid little features and thinking “that is pretty cool”. 😉
@support-rkalla wrote:
Agreed, quite a bit of work for a relatively small usability improvement. Maybe parsing out of the textfield, but even then that’s TLD-specific and doesn’t help if BEA offers something similiar in their TLDs, or Sun in their TLDs or maybe even Tapestry or other framework.
So the solution is something to what NOP said, running an internal server… in which case you might find just changing your docBase (For Tomcat) in your server’s config file to point to your dev webroot would provide you the functionality you needed; so you can just hit “refresh” in your browser and immediately see the new file.
Of course when deploying you’d want to have the deployment server configured differently 🙂
No, I would not think this to be impossible.
I don’t know exactly how the HTML preview currently operates, but I guess it is one of the two following approaches:
1. Real-time rendering: in this case the struts-html tags should be mapped with a hijacking TLD to another class-set that outputs user-specifiable dummy HTML, iterations should be preset to a specified number of loopings, and decision-like tags should be prefixed to be false or true.
2. Currently ignoring struts tags and only using the html tags. In this case the struts tags could be replaced with user-specifiable HTML code taken from configuration settings.
