Re: the dangers of Wicket's modifying given HTML
On 7/11/2014 2:25 AM, Martin Grigorov wrote: ... I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. Martin, I note that getMarkupSettings().setDefaultBeforeDisabledLink(...) et. al. are no longer available in Wicket 7.x. Does that mean that the HTML modification I complained about for disabled links no longer occurs in Wicket 7.x? It seems also that by default a disabled link will merely remove the href, which is fine. Do links in Wicket 7.x have any method hooks for modifying the HTML, or do they rely on behaviors? (I hope the latter.) Lastly, is there any existing AttributeModifier behavior that adds an attribute only if a component is disabled? (If not, that may be the perfect thing for me to make my first contribution.) Best, Garret
Re: the dangers of Wicket's modifying given HTML
I did a little searching, and it appears that the reference below does _not_ include anchor tags. However, HTML5 allows for a placeholder hyperlink http://www.w3.org/TR/html-markup/a.html by removal of the href attribute. That may be what we're looking for, and it appears (on cursory examination) that Wicket 7.x does this already (i.e. removes the href for disabled links). Garret On 7/11/2014 5:33 AM, Nick Pratt wrote: Does that include anchor tags? On Jul 11, 2014 8:11 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Fri, Jul 11, 2014 at 1:59 PM, Nick Pratt nbpr...@gmail.com wrote: Just curious - with regards to disabled links, what HTML is being suggested (or is the 2014 expected norm) as the replacement for the em/span in the disabled state? http://www.w3.org/TR/html5/disabled-elements.html Martijn
Re: the dangers of Wicket's modifying given HTML
On Sat, Jul 12, 2014 at 12:16 AM, Garret Wilson gar...@globalmentor.com wrote: On 7/11/2014 2:25 AM, Martin Grigorov wrote: ... I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. That sounds great! I'm going to update my client's project to the 7.0 release stream and go from there. I've already signed up on JIRA today. I have a few clarification questions: * Do we only have access to the source via Git, or is there a Subversion repository as well? We use Git for the code and Subversion for the site/guide (because Apache infrastructure). The main Git repo is https://git-wip-us.apache.org/repos/asf/wicket.git. It is being synchronized/mirrored to https://github.com/apache/wicket (every 2 hours, I think). * How often is the Maven SNAPSHOT repository updated? Is there a nightly or weekly build pushed to Maven? I ask because it would be nice if my client's official build would pull Wicket from some Maven repository rather than being linked to the actual source code, and if make a contribution it would be nice for it to propagate quickly to some official download, even if only a nightly. The SNAPSHOTs repo is https://repository.apache.org/content/repositories/snapshots/ After every push to https://git-wip-us.apache.org/repos/asf/wicket.git the CI server (http://ci.apache.org/builders/wicket-master) uploads the new -SNAPSHOTs to https://repository.apache.org/content/repositories/snapshots/ * If I just set my POM to point to the SNAPSHOT repository, will it just automatically pull down new versions, or is there something else I need to do? This should be enough. (I don't want to take this thread too far off topic; feel free to respond privately if you wish.) The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. Yes, I favor such an approach. I only now learned that there is a 7.x development stream---I'll direct my contributions there. Just to make it clear: - Wicket 7.x is Git master branch - Wicket 6.x is Git 'wicket-6.x' branch Best, Garret
Re: the dangers of Wicket's modifying given HTML
http://www.w3.org/TR/html5/disabled-elements.html 4.14.2 Pseudo-classes :enabled The :enabled http://www.w3.org/TR/html5/disabled-elements.html#selector-enabled pseudo-class must match any element falling into one of the following categories: - a http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element elements that have an href http://www.w3.org/TR/html5/links.html#attr-hyperlink-href attribute But different CSS frameworks (Bootstrap, Yahoo Pure, ...) have their own understanding what is disabled anchor. Bootstrap for example expects 'disabled' class to style the anchor as disabled - http://getbootstrap.com/css/#buttons-disabled. On Fri, Jul 11, 2014 at 3:33 PM, Nick Pratt nbpr...@gmail.com wrote: Does that include anchor tags? On Jul 11, 2014 8:11 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Fri, Jul 11, 2014 at 1:59 PM, Nick Pratt nbpr...@gmail.com wrote: Just curious - with regards to disabled links, what HTML is being suggested (or is the 2014 expected norm) as the replacement for the em/span in the disabled state? http://www.w3.org/TR/html5/disabled-elements.html Martijn
Re: the dangers of Wicket's modifying given HTML
On Fri, Jul 11, 2014 at 1:31 AM, Garret Wilson gar...@globalmentor.com wrote: Everyone, Wicket was created in a world in which little was done at display time to manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck around with the HTML given by the developer. But in today's world in which we use JavaScript libraries like jQuery to modify the DOM on a whim, and CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification of the HTML I give it can wreak havoc with my application. 1. Let me give you two examples. The first is BookmarkablePageLink. I have a simple and semantically useful navigation: nav ul lia wicket:id=homePageLink ... I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it turns into a beautiful menu with mouseover highlighting, selected items, etc. I use a BookmarkablePageLink to wrap each link. But some menu items are only available to users with certain permissions, so I want to disable some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my a tags are turned into ugly spanem tags, completely destroying the look of the menu because Yahoo! Pure CSS doesn't recognize spanem tags as menu items. Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) and friends, but I shouldn't have to. This is a holdover from the days when stylistic changes were made by changing the HTML, not by applying CSS. I recommend that by default links should not change the HTML, but instead add or remove a particular HTML class value. 2. The second example is CheckBoxMultipleChoice. I have a nice set up checkboxes in the HTML: div wicket:id=widgets label for=fooinput id=foo type=checkbox/ Foo/label label for=barinput id=bar type=checkbox/ Bar/label /div Created https://issues.apache.org/jira/browse/WICKET-5640 for p.2 Please comment in the ticket with suggestions what and how to improve. Without Wicket, those look nice; they are displayed horizontally, and the labels are beside the checkboxes: X FooX Bar But if I use CheckBoxMultipleChoice, it completely screws up the HTML! Suddenly my HTML looks like this: ...input .../label ...foo/labelbr/input .../label ...bar/labelbr/ Wicket has not only taken my input out of the label.../label, it has added an ugly, non-semantic br/ for styling. Why?? If I wanted to style my HTML with br/ (like I did around the year 1997), then I would have put it in the original HTML myself! And by taking the input out of the label, they are no longer a unit, and because of my CSS styling the labels now appear under the checkboxes---not to mention that Wicket has forced my checkboxes to be vertical instead of horizontal via the br/. Yes, I realize I can call CheckBoxMultipleChoice.setSuffix(), but again, I shouldn't have to. It turns out that for the moment I will have to abandon CheckBoxMultipleChoice altogether and do everything manually. Yes, I know I can remedy much of this manually by adding lots of boilerplate/setup code to what comes out of the box by default, turning off auto-generation of em and br/, etc. But that's one of the shortcomings of Wicket right now---to get it work like one would expect it to in the modern world of HTML5 and CSS3, one has to add lots of boilerplate code to change its defaults. Wicket was made to prevent boilerplate code. In summary, I'd like to encourage the developers going forward to tweak Wicket so that it doesn't change our HTML too much, it doesn't require us to undo the HTML that it forces on us, and plays much better in the modern world of HTML5, CSS3, and Ajax. And I'll be glad to help make that a reality! Best, Garret
Re: the dangers of Wicket's modifying given HTML
On 7/12/2014 11:10 AM, Martin Grigorov wrote: http://www.w3.org/TR/html5/disabled-elements.html 4.14.2 Pseudo-classes :enabled My understanding from reading the above link is that this is a pseudo-class to be used in CSS selectors---that is, to _select_ elements that are enabled. This thread initially addressed _how to make an element disabled_, and I don't think that adding :enabled to the element will change its enabled status---in fact, there is no :enabled class, which is why it is called a pseudo-class. However, reading between the lines, it appears that simply removing the href attribute from a will cause it to be disabled (a placeholder), and thus the CSS :enabled pseudo-class selector will not include it, which is what we want. Therefore the current behavior under Wicket 7.x (removing the href attribute) seems appropriate for disabling the a element. We need merely to provide a mechanism to easily specify certain CSS classes to be added when the state is disabled, and that's why I was thinking of a DisabledStatusAttributeModifier or something. That part is simple. The more interesting part is how to group together a bundle of declarative behaviors to be easily plugged in to work with various frameworks (e.g. Bootstrap, Pure). I have some ideas on this; I'll investigate more, and discuss them on WICKET-5460. Garret
Re: the dangers of Wicket's modifying given HTML
On 7/12/2014 11:00 AM, Martin Grigorov wrote: On Sat, Jul 12, 2014 at 8:33 PM, Garret Wilson gar...@globalmentor.com wrote: Martin, I note that getMarkupSettings().setDefaultBeforeDisabledLink(...) et. al. are no longer available in Wicket 7.x. Does that mean that the HTML modification I complained about for disabled links no longer occurs in Wicket 7.x? Take a look at https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0 Here we listed all changes introduced in 7.x The one about this particular change is https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0#MigrationtoWicket7.0-AbstractLinknolongeraltersitsmarkuptorenderitselfasdisabledWICKET-4904 Any feedback about improving the migration guide (making things more clear, etc) is very welcome! I think I missed it because I was searching for setDefaultBeforeDisabledLink, which has been removed from IMarkupSettings. It might be helpful to mention that as well. Garret
Re: the dangers of Wicket's modifying given HTML
On 7/11/2014 12:43 AM, Sven Meier wrote: Hi Garret, going forward to tweak Wicket so that it doesn't change our HTML too much we're working on it, see https://issues.apache.org/jira/browse/WICKET-4904 it doesn't require us to undo the HTML that it forces on us I fully agree. I'd be in favour to change CheckBoxMultipleChoice to have an empty suffix by default - we can change this for Wicket 7. Please create a Jira issue. Regards Sven Awesome! WICKET-4904 https://issues.apache.org/jira/browse/WICKET-4904 is exactly the issue I was raising, thanks. Garret P.S. I'm adding an HTML link to this email to be helpful. If it's not allowed on this list, please let me know.
Re: the dangers of Wicket's modifying given HTML
Hi Garret, going forward to tweak Wicket so that it doesn't change our HTML too much we're working on it, see https://issues.apache.org/jira/browse/WICKET-4904 it doesn't require us to undo the HTML that it forces on us I fully agree. I'd be in favour to change CheckBoxMultipleChoice to have an empty suffix by default - we can change this for Wicket 7. Please create a Jira issue. Regards Sven On 07/11/2014 12:31 AM, Garret Wilson wrote: Everyone, Wicket was created in a world in which little was done at display time to manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck around with the HTML given by the developer. But in today's world in which we use JavaScript libraries like jQuery to modify the DOM on a whim, and CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification of the HTML I give it can wreak havoc with my application. 1. Let me give you two examples. The first is BookmarkablePageLink. I have a simple and semantically useful navigation: nav ul lia wicket:id=homePageLink ... I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it turns into a beautiful menu with mouseover highlighting, selected items, etc. I use a BookmarkablePageLink to wrap each link. But some menu items are only available to users with certain permissions, so I want to disable some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my a tags are turned into ugly spanem tags, completely destroying the look of the menu because Yahoo! Pure CSS doesn't recognize spanem tags as menu items. Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) and friends, but I shouldn't have to. This is a holdover from the days when stylistic changes were made by changing the HTML, not by applying CSS. I recommend that by default links should not change the HTML, but instead add or remove a particular HTML class value. 2. The second example is CheckBoxMultipleChoice. I have a nice set up checkboxes in the HTML: div wicket:id=widgets label for=fooinput id=foo type=checkbox/ Foo/label label for=barinput id=bar type=checkbox/ Bar/label /div Without Wicket, those look nice; they are displayed horizontally, and the labels are beside the checkboxes: X FooX Bar But if I use CheckBoxMultipleChoice, it completely screws up the HTML! Suddenly my HTML looks like this: ...input .../label ...foo/labelbr/input .../label ...bar/labelbr/ Wicket has not only taken my input out of the label.../label, it has added an ugly, non-semantic br/ for styling. Why?? If I wanted to style my HTML with br/ (like I did around the year 1997), then I would have put it in the original HTML myself! And by taking the input out of the label, they are no longer a unit, and because of my CSS styling the labels now appear under the checkboxes---not to mention that Wicket has forced my checkboxes to be vertical instead of horizontal via the br/. Yes, I realize I can call CheckBoxMultipleChoice.setSuffix(), but again, I shouldn't have to. It turns out that for the moment I will have to abandon CheckBoxMultipleChoice altogether and do everything manually. Yes, I know I can remedy much of this manually by adding lots of boilerplate/setup code to what comes out of the box by default, turning off auto-generation of em and br/, etc. But that's one of the shortcomings of Wicket right now---to get it work like one would expect it to in the modern world of HTML5 and CSS3, one has to add lots of boilerplate code to change its defaults. Wicket was made to prevent boilerplate code. In summary, I'd like to encourage the developers going forward to tweak Wicket so that it doesn't change our HTML too much, it doesn't require us to undo the HTML that it forces on us, and plays much better in the modern world of HTML5, CSS3, and Ajax. And I'll be glad to help make that a reality! Best, Garret
Re: the dangers of Wicket's modifying given HTML
In my opinion these criticisms provide a way for us to discuss expected behaviour. I find it good to at least see where our conventional wisdom has grown old and should evolve. I'd like Garret to be able to freely provide his insights to where Wicket has different behaviour than a new comer expects. I did not take any offense in his writing, and found it well researched, knowledgable and respectful. I expect that Garret wants to first poll opinions before submitting a patch. This dev@ list is meant for discussion. And I suspect that the patch for e.g. 'fixing' links to not render different markup would be rather trivial and not worthy of much discussion other than Garret already told us. Martijn On Fri, Jul 11, 2014 at 2:49 AM, John Sarman johnsar...@gmail.com wrote: Garrett, Since Wicket is open source, why not create the desired patch and submit it to the committers instead of ranting about what caveats (in your opinion) exist. Productivity comes from contributions to code, not from complaining why it does not do it the way you think it should. Once you request a patch you will have the long time hard working devs scouring over the code to produce a better product. I did this approach and ultimately the long time devs rewrote the solution to my issue, and it is beautiful and simple. In summary, I'd like you to contribute the changes you desire to the codebase making sure that your ideas do not breaks the 1000's of other developers usage of the API. Thanks, John On Thu, Jul 10, 2014 at 6:31 PM, Garret Wilson gar...@globalmentor.com wrote: Everyone, Wicket was created in a world in which little was done at display time to manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck around with the HTML given by the developer. But in today's world in which we use JavaScript libraries like jQuery to modify the DOM on a whim, and CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification of the HTML I give it can wreak havoc with my application. 1. Let me give you two examples. The first is BookmarkablePageLink. I have a simple and semantically useful navigation: nav ul lia wicket:id=homePageLink ... I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it turns into a beautiful menu with mouseover highlighting, selected items, etc. I use a BookmarkablePageLink to wrap each link. But some menu items are only available to users with certain permissions, so I want to disable some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my a tags are turned into ugly spanem tags, completely destroying the look of the menu because Yahoo! Pure CSS doesn't recognize spanem tags as menu items. Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) and friends, but I shouldn't have to. This is a holdover from the days when stylistic changes were made by changing the HTML, not by applying CSS. I recommend that by default links should not change the HTML, but instead add or remove a particular HTML class value. 2. The second example is CheckBoxMultipleChoice. I have a nice set up checkboxes in the HTML: div wicket:id=widgets label for=fooinput id=foo type=checkbox/ Foo/label label for=barinput id=bar type=checkbox/ Bar/label /div Without Wicket, those look nice; they are displayed horizontally, and the labels are beside the checkboxes: X FooX Bar But if I use CheckBoxMultipleChoice, it completely screws up the HTML! Suddenly my HTML looks like this: ...input .../label ...foo/labelbr/input .../label ...bar/labelbr/ Wicket has not only taken my input out of the label.../label, it has added an ugly, non-semantic br/ for styling. Why?? If I wanted to style my HTML with br/ (like I did around the year 1997), then I would have put it in the original HTML myself! And by taking the input out of the label, they are no longer a unit, and because of my CSS styling the labels now appear under the checkboxes---not to mention that Wicket has forced my checkboxes to be vertical instead of horizontal via the br/. Yes, I realize I can call CheckBoxMultipleChoice.setSuffix(), but again, I shouldn't have to. It turns out that for the moment I will have to abandon CheckBoxMultipleChoice altogether and do everything manually. Yes, I know I can remedy much of this manually by adding lots of boilerplate/setup code to what comes out of the box by default, turning off auto-generation of em and br/, etc. But that's one of the shortcomings of Wicket right now---to get it work like one would expect it to in the modern world of HTML5 and CSS3, one has to add lots of boilerplate code to change its defaults. Wicket was made to prevent boilerplate code. In summary, I'd like to encourage the developers going forward to tweak Wicket so that it doesn't change our HTML too much, it doesn't require us to undo the HTML that it forces
Re: the dangers of Wicket's modifying given HTML
Hi, I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. About the non technical part. I also have concerns about the way you express your opinion. English is not my native language and I may misunderstood the meaning of some parts but I find your language a bit harsh. Please try to avoid doing this. I'm looking forward for your contributions! On Fri, Jul 11, 2014 at 1:31 AM, Garret Wilson gar...@globalmentor.com wrote: Everyone, Wicket was created in a world in which little was done at display time to manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck around with the HTML given by the developer. But in today's world in which we use JavaScript libraries like jQuery to modify the DOM on a whim, and CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification of the HTML I give it can wreak havoc with my application. 1. Let me give you two examples. The first is BookmarkablePageLink. I have a simple and semantically useful navigation: nav ul lia wicket:id=homePageLink ... I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it turns into a beautiful menu with mouseover highlighting, selected items, etc. I use a BookmarkablePageLink to wrap each link. But some menu items are only available to users with certain permissions, so I want to disable some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my a tags are turned into ugly spanem tags, completely destroying the look of the menu because Yahoo! Pure CSS doesn't recognize spanem tags as menu items. Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) and friends, but I shouldn't have to. This is a holdover from the days when stylistic changes were made by changing the HTML, not by applying CSS. I recommend that by default links should not change the HTML, but instead add or remove a particular HTML class value. 2. The second example is CheckBoxMultipleChoice. I have a nice set up checkboxes in the HTML: div wicket:id=widgets label for=fooinput id=foo type=checkbox/ Foo/label label for=barinput id=bar type=checkbox/ Bar/label /div Without Wicket, those look nice; they are displayed horizontally, and the labels are beside the checkboxes: X FooX Bar But if I use CheckBoxMultipleChoice, it completely screws up the HTML! Suddenly my HTML looks like this: ...input .../label ...foo/labelbr/input .../label ...bar/labelbr/ Wicket has not only taken my input out of the label.../label, it has added an ugly, non-semantic br/ for styling. Why?? If I wanted to style my HTML with br/ (like I did around the year 1997), then I would have put it in the original HTML myself! And by taking the input out of the label, they are no longer a unit, and because of my CSS styling the labels now appear under the checkboxes---not to mention that Wicket has forced my checkboxes to be vertical instead of horizontal via the br/. Yes, I realize I can call CheckBoxMultipleChoice.setSuffix(), but again, I shouldn't have to. It turns out that for the moment I will have to abandon CheckBoxMultipleChoice altogether and do everything manually. Yes, I know I can remedy much of this manually by adding lots of boilerplate/setup code to what comes out of the box by default, turning off auto-generation of em and br/, etc. But that's one of the shortcomings of Wicket right now---to get it work like one would expect it to in the modern world of HTML5 and CSS3, one has to add lots of boilerplate code to change its defaults. Wicket was made to prevent boilerplate code. In summary, I'd like to encourage the developers going forward to tweak Wicket so that it doesn't change our HTML too much, it doesn't require us to undo the HTML that it forces on us, and plays much better in the modern world of HTML5, CSS3, and Ajax. And I'll be glad to help make that a reality! Best, Garret
Re: the dangers of Wicket's modifying given HTML
On Fri, Jul 11, 2014 at 11:25 AM, Martin Grigorov mgrigo...@apache.org wrote: I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. Yup. 6.x should not pull the rug underneath existing users. About the non technical part. I also have concerns about the way you express your opinion. English is not my native language and I may misunderstood the meaning of some parts but I find your language a bit harsh. Please try to avoid doing this. It is strongly opinionated, especially given that it touches about the only two places where Wicket does this. Could it be worded differently, certainly. I do feel this comes from the right place: Wicket should walk the path of least surprise. In 2004-2005 when Wicket was envisioned, the link/checkbox behaviour was about what you'd expect of a web framework. Come 2010- the current behaviour doesn't meet expectations–it should be reversed for these two points (enable extension, but have default be non-modifying) Martijn
Re: the dangers of Wicket's modifying given HTML
On Fri, Jul 11, 2014 at 12:44 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Fri, Jul 11, 2014 at 11:25 AM, Martin Grigorov mgrigo...@apache.org wrote: I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. Yup. 6.x should not pull the rug underneath existing users. About the non technical part. I also have concerns about the way you express your opinion. English is not my native language and I may misunderstood the meaning of some parts but I find your language a bit harsh. Please try to avoid doing this. It is strongly opinionated, especially given that it touches about the only two places where Wicket does this. Could it be worded They are not many but definitely not just two. RadioChoice have the same problem with prefix/suffix. https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/form/BootstrapRadioChoice.java#L67 https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/form/BootstrapRadioChoice.java#L105 does a lot just to un-mangle the HTML produced by Wicket's default component. differently, certainly. I do feel this comes from the right place: Wicket should walk the path of least surprise. In 2004-2005 when Wicket was envisioned, the link/checkbox behaviour was about what you'd expect of a web framework. Come 2010- the current behaviour doesn't meet expectations–it should be reversed for these two points (enable extension, but have default be non-modifying) Fully agree with the technical part of the Garret's mail ! Martijn
Re: the dangers of Wicket's modifying given HTML
Garrett, I also apologize for seeming to strong in my attempt to motivate you to produce a patch. I do know from experience that patches (pull requests) are the best motivators to the committers. So my counter rant was purely motivational (at least an attempt :) to enhance the codebase. John On Thu, Jul 10, 2014 at 11:32 PM, Garret Wilson gar...@globalmentor.com wrote: John, I sincerely apologize if this came across as a rant. I fully intend to start contributing to Wicket!! Since I'm new to this group, my intention was to explain a little about some of the architectural philosophy I will take in my contributions. I also wanted to engender some discussion of others' opinions and experiences before I rush off and start spewing out code. In short, once I map out a few areas that I think need improvements, the discussions on this list will give me an idea of where I can be most useful to start at. Best, Garret On 7/10/2014 5:49 PM, John Sarman wrote: Garrett, Since Wicket is open source, why not create the desired patch and submit it to the committers instead of ranting about what caveats (in your opinion) exist. Productivity comes from contributions to code, not from complaining why it does not do it the way you think it should. Once you request a patch you will have the long time hard working devs scouring over the code to produce a better product. I did this approach and ultimately the long time devs rewrote the solution to my issue, and it is beautiful and simple. In summary, I'd like you to contribute the changes you desire to the codebase making sure that your ideas do not breaks the 1000's of other developers usage of the API. Thanks, John
Re: the dangers of Wicket's modifying given HTML
Just curious - with regards to disabled links, what HTML is being suggested (or is the 2014 expected norm) as the replacement for the em/span in the disabled state? N On Jul 11, 2014 7:47 AM, John Sarman johnsar...@gmail.com wrote: Garrett, I also apologize for seeming to strong in my attempt to motivate you to produce a patch. I do know from experience that patches (pull requests) are the best motivators to the committers. So my counter rant was purely motivational (at least an attempt :) to enhance the codebase. John On Thu, Jul 10, 2014 at 11:32 PM, Garret Wilson gar...@globalmentor.com wrote: John, I sincerely apologize if this came across as a rant. I fully intend to start contributing to Wicket!! Since I'm new to this group, my intention was to explain a little about some of the architectural philosophy I will take in my contributions. I also wanted to engender some discussion of others' opinions and experiences before I rush off and start spewing out code. In short, once I map out a few areas that I think need improvements, the discussions on this list will give me an idea of where I can be most useful to start at. Best, Garret On 7/10/2014 5:49 PM, John Sarman wrote: Garrett, Since Wicket is open source, why not create the desired patch and submit it to the committers instead of ranting about what caveats (in your opinion) exist. Productivity comes from contributions to code, not from complaining why it does not do it the way you think it should. Once you request a patch you will have the long time hard working devs scouring over the code to produce a better product. I did this approach and ultimately the long time devs rewrote the solution to my issue, and it is beautiful and simple. In summary, I'd like you to contribute the changes you desire to the codebase making sure that your ideas do not breaks the 1000's of other developers usage of the API. Thanks, John
Re: the dangers of Wicket's modifying given HTML
On Fri, Jul 11, 2014 at 1:59 PM, Nick Pratt nbpr...@gmail.com wrote: Just curious - with regards to disabled links, what HTML is being suggested (or is the 2014 expected norm) as the replacement for the em/span in the disabled state? http://www.w3.org/TR/html5/disabled-elements.html Martijn
Re: the dangers of Wicket's modifying given HTML
Does that include anchor tags? On Jul 11, 2014 8:11 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Fri, Jul 11, 2014 at 1:59 PM, Nick Pratt nbpr...@gmail.com wrote: Just curious - with regards to disabled links, what HTML is being suggested (or is the 2014 expected norm) as the replacement for the em/span in the disabled state? http://www.w3.org/TR/html5/disabled-elements.html Martijn
Re: the dangers of Wicket's modifying given HTML
On 7/11/2014 2:25 AM, Martin Grigorov wrote: ... I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. That sounds great! I'm going to update my client's project to the 7.0 release stream and go from there. I've already signed up on JIRA today. I have a few clarification questions: * Do we only have access to the source via Git, or is there a Subversion repository as well? * How often is the Maven SNAPSHOT repository updated? Is there a nightly or weekly build pushed to Maven? I ask because it would be nice if my client's official build would pull Wicket from some Maven repository rather than being linked to the actual source code, and if make a contribution it would be nice for it to propagate quickly to some official download, even if only a nightly. * If I just set my POM to point to the SNAPSHOT repository, will it just automatically pull down new versions, or is there something else I need to do? (I don't want to take this thread too far off topic; feel free to respond privately if you wish.) The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. Yes, I favor such an approach. I only now learned that there is a 7.x development stream---I'll direct my contributions there. Best, Garret
Re: the dangers of Wicket's modifying given HTML
Simplest way to get started is to create a Github account, which is where wicket is hosted, setup the github app on your PC if using windows. Then just fork wicket to your personal github account. After that just use the app to download to your PC make changes push the changes back to your fork, then create a pull request. On Fri, Jul 11, 2014 at 5:16 PM, Garret Wilson gar...@globalmentor.com wrote: On 7/11/2014 2:25 AM, Martin Grigorov wrote: ... I recommend you to use Wicket 7.0.0-M2 for new development. It is quite stable! I use it for a personal applications. That sounds great! I'm going to update my client's project to the 7.0 release stream and go from there. I've already signed up on JIRA today. I have a few clarification questions: * Do we only have access to the source via Git, or is there a Subversion repository as well? * How often is the Maven SNAPSHOT repository updated? Is there a nightly or weekly build pushed to Maven? I ask because it would be nice if my client's official build would pull Wicket from some Maven repository rather than being linked to the actual source code, and if make a contribution it would be nice for it to propagate quickly to some official download, even if only a nightly. * If I just set my POM to point to the SNAPSHOT repository, will it just automatically pull down new versions, or is there something else I need to do? (I don't want to take this thread too far off topic; feel free to respond privately if you wish.) The benefit is that some of these things are improved there (e.g. p.1) and it is possible to make more radical changes. Changing the default behavior for p.2 will make Wicket's HTML not so *ugly* but will break many applications in production. No matter how ugly is the generated code I'll veto such change in 6.x. Yes, I favor such an approach. I only now learned that there is a 7.x development stream---I'll direct my contributions there. Best, Garret
Re: the dangers of Wicket's modifying given HTML
Garrett, Since Wicket is open source, why not create the desired patch and submit it to the committers instead of ranting about what caveats (in your opinion) exist. Productivity comes from contributions to code, not from complaining why it does not do it the way you think it should. Once you request a patch you will have the long time hard working devs scouring over the code to produce a better product. I did this approach and ultimately the long time devs rewrote the solution to my issue, and it is beautiful and simple. In summary, I'd like you to contribute the changes you desire to the codebase making sure that your ideas do not breaks the 1000's of other developers usage of the API. Thanks, John On Thu, Jul 10, 2014 at 6:31 PM, Garret Wilson gar...@globalmentor.com wrote: Everyone, Wicket was created in a world in which little was done at display time to manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck around with the HTML given by the developer. But in today's world in which we use JavaScript libraries like jQuery to modify the DOM on a whim, and CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification of the HTML I give it can wreak havoc with my application. 1. Let me give you two examples. The first is BookmarkablePageLink. I have a simple and semantically useful navigation: nav ul lia wicket:id=homePageLink ... I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it turns into a beautiful menu with mouseover highlighting, selected items, etc. I use a BookmarkablePageLink to wrap each link. But some menu items are only available to users with certain permissions, so I want to disable some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my a tags are turned into ugly spanem tags, completely destroying the look of the menu because Yahoo! Pure CSS doesn't recognize spanem tags as menu items. Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) and friends, but I shouldn't have to. This is a holdover from the days when stylistic changes were made by changing the HTML, not by applying CSS. I recommend that by default links should not change the HTML, but instead add or remove a particular HTML class value. 2. The second example is CheckBoxMultipleChoice. I have a nice set up checkboxes in the HTML: div wicket:id=widgets label for=fooinput id=foo type=checkbox/ Foo/label label for=barinput id=bar type=checkbox/ Bar/label /div Without Wicket, those look nice; they are displayed horizontally, and the labels are beside the checkboxes: X FooX Bar But if I use CheckBoxMultipleChoice, it completely screws up the HTML! Suddenly my HTML looks like this: ...input .../label ...foo/labelbr/input .../label ...bar/labelbr/ Wicket has not only taken my input out of the label.../label, it has added an ugly, non-semantic br/ for styling. Why?? If I wanted to style my HTML with br/ (like I did around the year 1997), then I would have put it in the original HTML myself! And by taking the input out of the label, they are no longer a unit, and because of my CSS styling the labels now appear under the checkboxes---not to mention that Wicket has forced my checkboxes to be vertical instead of horizontal via the br/. Yes, I realize I can call CheckBoxMultipleChoice.setSuffix(), but again, I shouldn't have to. It turns out that for the moment I will have to abandon CheckBoxMultipleChoice altogether and do everything manually. Yes, I know I can remedy much of this manually by adding lots of boilerplate/setup code to what comes out of the box by default, turning off auto-generation of em and br/, etc. But that's one of the shortcomings of Wicket right now---to get it work like one would expect it to in the modern world of HTML5 and CSS3, one has to add lots of boilerplate code to change its defaults. Wicket was made to prevent boilerplate code. In summary, I'd like to encourage the developers going forward to tweak Wicket so that it doesn't change our HTML too much, it doesn't require us to undo the HTML that it forces on us, and plays much better in the modern world of HTML5, CSS3, and Ajax. And I'll be glad to help make that a reality! Best, Garret
Re: the dangers of Wicket's modifying given HTML
Almost no Wicket component actually generate/modify the HTML structure. You just cited 2 of the very few cases (the only others I can think of are part of the 'extensions' module, which you don't need to use if you don't want to). Just try to do the same with RichFaces :) It can't be expected that the generated markup matches exactly what your specific CSS framework wants (since every framework expects something different), but I do agree that there should always be customization hooks for these kind of customization. For the specific cases you complained about, there are such hooks, they just may don't be as obvious and convenient as you may want: For the disabled links, you may override AbstractLink.disableLink(ComponentTag) and change it to whatever you want. Since Java doesn't have mixins, you may have to override this same method in the various AbstractLink subclasses you use (make it a static method in an utility class to avoid too much repetition). For CheckBoxMultipleChoice, you may override the CheckBoxMultipleChoice.appendOptionHtml() method, and generate exactly the markup you want. The method is a little longer than the ideal, but it centralizes the HTML generation for the items, so it's the only one you have to rewrite. You can also use CheckGroup+Check instead, and specify the exact HTML you want, if you prefer. One of the beauties of Wicket is that its code is fairly easy to read, and has plenty of hooks to customize its behavior. And even if they are not sufficient (due some final method, for example), the components usually are simple and decoupled from the core. You can just copy the component source into your project (with different names or packages, to avoid classloader hell) and just modify it to your heart's content. Again, imagine how much fun it would be to do the same with JSF's render kits or Swing`s LaFs :) Tetsuo “The truth is rarely pure and never simple.” ― Oscar Wilde On Thu, Jul 10, 2014 at 9:49 PM, John Sarman johnsar...@gmail.com wrote: Garrett, Since Wicket is open source, why not create the desired patch and submit it to the committers instead of ranting about what caveats (in your opinion) exist. Productivity comes from contributions to code, not from complaining why it does not do it the way you think it should. Once you request a patch you will have the long time hard working devs scouring over the code to produce a better product. I did this approach and ultimately the long time devs rewrote the solution to my issue, and it is beautiful and simple. In summary, I'd like you to contribute the changes you desire to the codebase making sure that your ideas do not breaks the 1000's of other developers usage of the API. Thanks, John On Thu, Jul 10, 2014 at 6:31 PM, Garret Wilson gar...@globalmentor.com wrote: Everyone, Wicket was created in a world in which little was done at display time to manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck around with the HTML given by the developer. But in today's world in which we use JavaScript libraries like jQuery to modify the DOM on a whim, and CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification of the HTML I give it can wreak havoc with my application. 1. Let me give you two examples. The first is BookmarkablePageLink. I have a simple and semantically useful navigation: nav ul lia wicket:id=homePageLink ... I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it turns into a beautiful menu with mouseover highlighting, selected items, etc. I use a BookmarkablePageLink to wrap each link. But some menu items are only available to users with certain permissions, so I want to disable some of them. Oops! When I call BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my a tags are turned into ugly spanem tags, completely destroying the look of the menu because Yahoo! Pure CSS doesn't recognize spanem tags as menu items. Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...) and friends, but I shouldn't have to. This is a holdover from the days when stylistic changes were made by changing the HTML, not by applying CSS. I recommend that by default links should not change the HTML, but instead add or remove a particular HTML class value. 2. The second example is CheckBoxMultipleChoice. I have a nice set up checkboxes in the HTML: div wicket:id=widgets label for=fooinput id=foo type=checkbox/ Foo/label label for=barinput id=bar type=checkbox/ Bar/label /div Without Wicket, those look nice; they are displayed horizontally, and the labels are beside the checkboxes: X FooX Bar But if I use CheckBoxMultipleChoice, it completely screws up the HTML! Suddenly my HTML looks like this: ...input .../label ...foo/labelbr/input .../label ...bar/labelbr/ Wicket has not only taken my input out of the label.../label, it has added an ugly,
Re: the dangers of Wicket's modifying given HTML
John, I sincerely apologize if this came across as a rant. I fully intend to start contributing to Wicket!! Since I'm new to this group, my intention was to explain a little about some of the architectural philosophy I will take in my contributions. I also wanted to engender some discussion of others' opinions and experiences before I rush off and start spewing out code. In short, once I map out a few areas that I think need improvements, the discussions on this list will give me an idea of where I can be most useful to start at. Best, Garret On 7/10/2014 5:49 PM, John Sarman wrote: Garrett, Since Wicket is open source, why not create the desired patch and submit it to the committers instead of ranting about what caveats (in your opinion) exist. Productivity comes from contributions to code, not from complaining why it does not do it the way you think it should. Once you request a patch you will have the long time hard working devs scouring over the code to produce a better product. I did this approach and ultimately the long time devs rewrote the solution to my issue, and it is beautiful and simple. In summary, I'd like you to contribute the changes you desire to the codebase making sure that your ideas do not breaks the 1000's of other developers usage of the API. Thanks, John
