Re: [OS-webwork] ui:hidden and ui:submit
Agreed! But please don't loose site of the ww:property tag arguments either. It really is doing two jobs and the only reason we like it (I like it too!) and it makes sense (makes sense to me!) is because we've grown accustomed to it. But you cannot deny it is doing two different jobs: push and print. An intuitive design would be to have two different tags. It's what is logical for the majority of people not familiar with WebWork. So a compromise would be to keep ww:property but add ww:push and ww:print. -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 2:09 PM Subject: [OS-webwork] ui:hidden and ui:submit Actually, while I've pretty much agreed with Maurice on every single point he's made, this is one case where I agree that ui:hidden and ui:submit would make sense. Webwork is proud of the fact that it's so skinnable. The fact that you can easily swap in templates for any form elements is tremendously useful. Picture a 'debug' skin, which would actually display the hidden tags. Now isn't that so much nicer than having to trawl through a source view of your html? The same argument can be made for submit buttons/imgs, I think. It's just pleasant being able to swap so easily, it'd give that exact warm fuzzy feeling I get when I trivially change one line somewhere to make all my textfields have a cute question mark next to them that points to live help, or define a 'required' parameter that automatically highlights them, etc etc. Quoting Patrick Lightbody [EMAIL PROTECTED]: Anders has had a good point all along. ww:property/ is really doing two jobs: push and print. We are all OK with it because we're used to it. But his post below of course looks completely silly... why would you want ww:property/ to do push, print, AND include. That's just silly, right? Well, now move your perspective to someone who hasn't used ww:property/ for 2 years. Move it to a WebWork newbie, but someone who is still smart and can see the obvious misnomer of property. Try real hard before you dismiss it. Open your mind up. And then remember you can still have property for compatibility and for people that are used to it, but ww:print property=foo/ and ww:push property=foo.../ww:push would make a hell of a lot more sense. OK, now let's think about ui:hidden/, another good idea shot down. Imagine you are new to webwork, but you're a good developer that has never read much documentation, since most good APIs just work like they should. So you wrote a JSP with ui:textfield/ and ui:select/, and then, since hidden is just another type of input, you decided to write ui:hidden/, since that makes sense (I mean, you've got a UI tag for everything else). Again, try hard before you dismiss it. Don't say, well hidden doesn't need error messages, so we shouldn't include it. Open your mind up -- try to be THAT person described above. It's a matter of doing what a smart newbie would most likely do. I know I would. I just had to add a hidden tag to a JSP page that used exclusively JSP taglibs (WebWork's UI tags as well as some custom helpers). But since there was no hidden, I crapped up the JSP with HTML. Does that really make sense -- especially for an incredibly small addition that completes the set of mapping from WebWork tags to HTML input tags? -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 1:29 PM Subject: Re: [OS-webwork] more flexible property tag Again, that age old questionwhy? Why this hatred of the unloved and unappreciate if/iterator tags? What have they ever done to you? Quoting boxed [EMAIL PROTECTED]: I've had a most enlightening conversation on irc recently. A friend of mine pointed out that property tag and iterator tag can be merged: ww:property value=foo do something /ww:property can iterate through the values if foo is a collection. Furthermore, we can merge the property tag and the if tag: ww:property value=foo do something /ww:property will do something if foo evaluates to not null (and if it's a boolean type to true). But wait! There's more! We can also merge it with the include tag: ww:property value='foo.jsp'/ can do an include if foo.jsp exists. We can also make it handle actions: ww:property value='foo.action'/ can do just what ww:action value='foo.action'/ does today if the string evaluates to an action! You wanted a flexible property tag mike (The property tag is flexible - not confusing! as you so nicely put it). Time you show that you mean it. // Anders Hovmöller PS. Yes it's sarcasm, but note that the first two examples are real world example from my friends version of the property tag for his
Re: [OS-webwork] ui:hidden and ui:submit
Argh, give up! We've argued propertytag to death, we agreed that the solution is to ensure the documentation is clear. Enough already! I'm reminded of the boy who cried wolf, to be honest. If someone keeps repeating the same thing over and over again (that others disagree with), then when that person actually says something insightful that's worth listening to, people will assume it's the same old nonsense just out of sheer habit. Quoting Patrick Lightbody [EMAIL PROTECTED]: Agreed! But please don't loose site of the ww:property tag arguments either. It really is doing two jobs and the only reason we like it (I like it too!) and it makes sense (makes sense to me!) is because we've grown accustomed to it. But you cannot deny it is doing two different jobs: push and print. An intuitive design would be to have two different tags. It's what is logical for the majority of people not familiar with WebWork. So a compromise would be to keep ww:property but add ww:push and ww:print. -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 2:09 PM Subject: [OS-webwork] ui:hidden and ui:submit Actually, while I've pretty much agreed with Maurice on every single point he's made, this is one case where I agree that ui:hidden and ui:submit would make sense. Webwork is proud of the fact that it's so skinnable. The fact that you can easily swap in templates for any form elements is tremendously useful. Picture a 'debug' skin, which would actually display the hidden tags. Now isn't that so much nicer than having to trawl through a source view of your html? The same argument can be made for submit buttons/imgs, I think. It's just pleasant being able to swap so easily, it'd give that exact warm fuzzy feeling I get when I trivially change one line somewhere to make all my textfields have a cute question mark next to them that points to live help, or define a 'required' parameter that automatically highlights them, etc etc. Quoting Patrick Lightbody [EMAIL PROTECTED]: Anders has had a good point all along. ww:property/ is really doing two jobs: push and print. We are all OK with it because we're used to it. But his post below of course looks completely silly... why would you want ww:property/ to do push, print, AND include. That's just silly, right? Well, now move your perspective to someone who hasn't used ww:property/ for 2 years. Move it to a WebWork newbie, but someone who is still smart and can see the obvious misnomer of property. Try real hard before you dismiss it. Open your mind up. And then remember you can still have property for compatibility and for people that are used to it, but ww:print property=foo/ and ww:push property=foo.../ww:push would make a hell of a lot more sense. OK, now let's think about ui:hidden/, another good idea shot down. Imagine you are new to webwork, but you're a good developer that has never read much documentation, since most good APIs just work like they should. So you wrote a JSP with ui:textfield/ and ui:select/, and then, since hidden is just another type of input, you decided to write ui:hidden/, since that makes sense (I mean, you've got a UI tag for everything else). Again, try hard before you dismiss it. Don't say, well hidden doesn't need error messages, so we shouldn't include it. Open your mind up -- try to be THAT person described above. It's a matter of doing what a smart newbie would most likely do. I know I would. I just had to add a hidden tag to a JSP page that used exclusively JSP taglibs (WebWork's UI tags as well as some custom helpers). But since there was no hidden, I crapped up the JSP with HTML. Does that really make sense -- especially for an incredibly small addition that completes the set of mapping from WebWork tags to HTML input tags? -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 1:29 PM Subject: Re: [OS-webwork] more flexible property tag Again, that age old questionwhy? Why this hatred of the unloved and unappreciate if/iterator tags? What have they ever done to you? Quoting boxed [EMAIL PROTECTED]: I've had a most enlightening conversation on irc recently. A friend of mine pointed out that property tag and iterator tag can be merged: ww:property value=foo do something /ww:property can iterate through the values if foo is a collection. Furthermore, we can merge the property tag and the if tag: ww:property value=foo do something /ww:property will do something if foo evaluates to not null (and if it's a boolean type to true). But wait! There's more! We can also merge it with the
Re: [OS-webwork] ui:hidden and ui:submit
On Wednesday, November 6, 2002, at 04:09 PM, Hani Suleiman wrote: Actually, while I've pretty much agreed with Maurice on every single point he's made, this is one case where I agree that ui:hidden and ui:submit would make sense. Hey, just because Patrick wrote it doesn't mean I disagree with it. ;-) As to skinning UI elements, event driven actions, and replacing PropertyEditors, I think that this all belongs together in a separate discussion which includes supporting JavaServerFaces. The JSF spec has all this and more and would be at least a good place to start. But, that's a can of worms I don't want to open until after a 1.3 release. If anyone has points or ideas that they want to save for a future discussion, there is already a JSF support item in Jira. -Maurice Webwork is proud of the fact that it's so skinnable. The fact that you can easily swap in templates for any form elements is tremendously useful. Picture a 'debug' skin, which would actually display the hidden tags. Now isn't that so much nicer than having to trawl through a source view of your html? The same argument can be made for submit buttons/imgs, I think. It's just pleasant being able to swap so easily, it'd give that exact warm fuzzy feeling I get when I trivially change one line somewhere to make all my textfields have a cute question mark next to them that points to live help, or define a 'required' parameter that automatically highlights them, etc etc. Quoting Patrick Lightbody [EMAIL PROTECTED]: Anders has had a good point all along. ww:property/ is really doing two jobs: push and print. We are all OK with it because we're used to it. But his post below of course looks completely silly... why would you want ww:property/ to do push, print, AND include. That's just silly, right? Well, now move your perspective to someone who hasn't used ww:property/ for 2 years. Move it to a WebWork newbie, but someone who is still smart and can see the obvious misnomer of property. Try real hard before you dismiss it. Open your mind up. And then remember you can still have property for compatibility and for people that are used to it, but ww:print property=foo/ and ww:push property=foo.../ww:push would make a hell of a lot more sense. OK, now let's think about ui:hidden/, another good idea shot down. Imagine you are new to webwork, but you're a good developer that has never read much documentation, since most good APIs just work like they should. So you wrote a JSP with ui:textfield/ and ui:select/, and then, since hidden is just another type of input, you decided to write ui:hidden/, since that makes sense (I mean, you've got a UI tag for everything else). Again, try hard before you dismiss it. Don't say, well hidden doesn't need error messages, so we shouldn't include it. Open your mind up -- try to be THAT person described above. It's a matter of doing what a smart newbie would most likely do. I know I would. I just had to add a hidden tag to a JSP page that used exclusively JSP taglibs (WebWork's UI tags as well as some custom helpers). But since there was no hidden, I crapped up the JSP with HTML. Does that really make sense -- especially for an incredibly small addition that completes the set of mapping from WebWork tags to HTML input tags? -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 1:29 PM Subject: Re: [OS-webwork] more flexible property tag Again, that age old questionwhy? Why this hatred of the unloved and unappreciate if/iterator tags? What have they ever done to you? Quoting boxed [EMAIL PROTECTED]: I've had a most enlightening conversation on irc recently. A friend of mine pointed out that property tag and iterator tag can be merged: ww:property value=foo do something /ww:property can iterate through the values if foo is a collection. Furthermore, we can merge the property tag and the if tag: ww:property value=foo do something /ww:property will do something if foo evaluates to not null (and if it's a boolean type to true). But wait! There's more! We can also merge it with the include tag: ww:property value='foo.jsp'/ can do an include if foo.jsp exists. We can also make it handle actions: ww:property value='foo.action'/ can do just what ww:action value='foo.action'/ does today if the string evaluates to an action! You wanted a flexible property tag mike (The property tag is flexible - not confusing! as you so nicely put it). Time you show that you mean it. // Anders Hovmöller PS. Yes it's sarcasm, but note that the first two examples are real world example from my friends version of the property tag for his framework DS. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
