You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "bernard (JIRA)" <ji...@apache.org> on 2010/03/31 21:51:28 UTC
[jira] Created: (WICKET-2814) Complete Support of Separation of
Markup from Java Files
Complete Support of Separation of Markup from Java Files
--------------------------------------------------------
Key: WICKET-2814
URL: https://issues.apache.org/jira/browse/WICKET-2814
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.5-M1
Reporter: bernard
Priority: Critical
First sentence on wicket.apache.org:
"With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML,
Apache Wicket makes developing web-apps simple and enjoyable again."
This mark-up/logic separation is indeed quite good and there is no doubt about it.
However, its default configuration, and this is the only one that the excellent IDE plugin for NetBeans supports, requires that HTML files are stored in the same Java package directory as the corresponding Java source files.
One reason for this request is that I want to use IDE support for HTML files not only for Java files. The other reason is that the disadvantages of storing HTML files in Java packages keep piling up, because it is just bad practice and it is an uphill battle to get tools to cooperate.
Requests for information about alternate storage locations are responded to with a reference to Wicket's extension mechanisms that indeed allow the HTML files to be stored anywhere.
Please refer to "Control where HTML files are loaded from" at http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
While this extension mechanism seems elegant at first, it exists only in theory because it does not achieve the results that developers have in mind - in fact it creates additional problems and finally some developers who try it don't use it.
Editors cannot resolve paths of resources e.g. style sheets, script files referred to by source attributes. It is inconvenient to not find resource files e.g. JavaScript files in the same directory structure as the HTML/Java files because an editor cannot resolve a relative path in the src attibute. Example: <script src="jslib/jquery-1.3.2.min.js> does not exist in java packages.
New IDE markup editing features such as HTML code completion and refactoring cannot be used in this configuration.
There are other heavy disadvantages of the current default such as performance issues with deploy on save.
The "Deploy on Save" feature in IDE development is a great time saver as it reduces the
redeployment after single file changes to the redeployment of single files. HTML file changes
have neglegible impact on the development process because they are only copied from the web directory.
However if web files are in the java package directory then due to assumptions that the IDE makes, the whole application has to be reloaded which is an expensive, irritating process.
This is a request to make file separation the default, and implement a change to make it work.
The default should be a HTML package structure that mirrors the Java package structure.
The default location in the document root should be masked by the url-pattern entry in the filter mapping in the web.xml file e.g. /wicket so that the static content is invisible by the web server.
Resolve paths such as "../../style.css" relative to the package structure not root as present e.g, "style.css".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2814) Complete Support of Separation of
Markup from Java Files
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-2814.
-----------------------------------
Resolution: Won't Fix
Assignee: Igor Vaynberg
we like keeping html files next to java files. there are a ton of advantages that come with this.
all the relative paths can be made to work by putting references to css and js inside wicket:link tags and keeping those files next to java files as well.
i dont want to go into the details, this has been discussed many many times on the list. if you read the threads you will notice that people who are new to wicket try to do what you do because they claim that "this is not a best practice" - whatever that means, but eventually come around to our point of view once they try to go with their approach and rediscover various problems that we have discovered long ago.
sounds like the biggest problem you are having is that the tools you are using are not configurable enough.
> Complete Support of Separation of Markup from Java Files
> --------------------------------------------------------
>
> Key: WICKET-2814
> URL: https://issues.apache.org/jira/browse/WICKET-2814
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M1
> Reporter: bernard
> Assignee: Igor Vaynberg
> Priority: Critical
>
> First sentence on wicket.apache.org:
> "With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML,
> Apache Wicket makes developing web-apps simple and enjoyable again."
> This mark-up/logic separation is indeed quite good and there is no doubt about it.
> However, its default configuration, and this is the only one that the excellent IDE plugin for NetBeans supports, requires that HTML files are stored in the same Java package directory as the corresponding Java source files.
> One reason for this request is that I want to use IDE support for HTML files not only for Java files. The other reason is that the disadvantages of storing HTML files in Java packages keep piling up, because it is just bad practice and it is an uphill battle to get tools to cooperate.
> Requests for information about alternate storage locations are responded to with a reference to Wicket's extension mechanisms that indeed allow the HTML files to be stored anywhere.
> Please refer to "Control where HTML files are loaded from" at http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html
> While this extension mechanism seems elegant at first, it exists only in theory because it does not achieve the results that developers have in mind - in fact it creates additional problems and finally some developers who try it don't use it.
> Editors cannot resolve paths of resources e.g. style sheets, script files referred to by source attributes. It is inconvenient to not find resource files e.g. JavaScript files in the same directory structure as the HTML/Java files because an editor cannot resolve a relative path in the src attibute. Example: <script src="jslib/jquery-1.3.2.min.js> does not exist in java packages.
> New IDE markup editing features such as HTML code completion and refactoring cannot be used in this configuration.
> There are other heavy disadvantages of the current default such as performance issues with deploy on save.
> The "Deploy on Save" feature in IDE development is a great time saver as it reduces the
> redeployment after single file changes to the redeployment of single files. HTML file changes
> have neglegible impact on the development process because they are only copied from the web directory.
> However if web files are in the java package directory then due to assumptions that the IDE makes, the whole application has to be reloaded which is an expensive, irritating process.
> This is a request to make file separation the default, and implement a change to make it work.
> The default should be a HTML package structure that mirrors the Java package structure.
> The default location in the document root should be masked by the url-pattern entry in the filter mapping in the web.xml file e.g. /wicket so that the static content is invisible by the web server.
> Resolve paths such as "../../style.css" relative to the package structure not root as present e.g, "style.css".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.