Re: Wicket Visibility vs. CSS visibility
Many people expect that is the component is not visible also the models and the data ias not called or touched. Because there state cant be resolved correctly. Als security is depending on it, it can never be that some thing where security says it is not visible/cant render that is still renders data, this would be a major security hole. On 5/17/08, Kirk Israel [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 7:34 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). I'm still not comfortable with is it visible being mixed up with is it plain gone... Here was my scenario, I'll tell you my error, the fix, and then I'd love to hear if there's a better way. Essentially we have a form where you can select countries, and we want to offer two different views, a flat list collection of checkboxes for all countries, and then a series of lists broken out by continent -- two checkgroups w/ the same underlying model. For screen realestate reasons, the CheckGroups live in scrollable Divs, and the Checks live in a special ListView thing. So far so good. Then each of the Continents has a little summary part, a textual description of what's selected (the idea is the comma separated summary is always visible vs. the checks which might be scrolled away, and the summary can be clever and concise and say ALL EUROPE except France, Spain) So - and I know this is a little bit of an anti-pattern - as I built each Continent I added the Summary label, and then kept a member variable list of those around, and then had the checkboxes (whether on the flat list or the by-continent list) call a function to add the summaries to the Ajax request target. What I didn't realize, when I made the by-continent view not visible and the flat list visible, and then back, the Continents actually got regenerated, with new Summary labels, and so the List was full of stale label referenes that barfed when I tried to update them. I know it's not encouraged to keep member variables of page components around, but I couldn't think of another way of getting to them... The net-net is, it seems very odd to me that merely switching around visibility should invalidate object references, that the complexity in actually USING the visibility outweighs the efficiency for free, and I wish I had a simple render this, but set its CSS visibility to hidden switch without having to go and manually modify attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
On Sat, May 17, 2008 at 2:46 AM, Johan Compagner [EMAIL PROTECTED] wrote: Many people expect that is the component is not visible also the models and the data ias not called or touched. Because there state cant be resolved correctly. Still seems a little odd to me. We're adding a component, but we're counting on it not to do anything. Because it's not visible. So it's not really there. But we put it there anyway! Als security is depending on it, it can never be that some thing where security says it is not visible/cant render that is still renders data, this would be a major security hole. OK, this is the first time I've started to hear a reasonable explanations as to why visibility = absence might be useful -- to me it seemed like a pain, with a fair chunk of boilerplate (.setOutputMarkupId(true); and .setOutputMarkupPlaceholderTag(true);) to get things to work correctly, and then unreliability as expectations of a component being ready to go (and not redrawn) aren't met. Part of it is, my main wicket experience hasn't depended on visibility as security; the main app I've been working on doesn't have like a superuser mode, permissions are mostly handled at the API layer and everyone gets about the same view of every screen. (And if I *did* have more user role based components on a single screen, I'd probably consider using a base class, with one subclass being the functional version for people with rights to see it, and one as a placeholder for those who don't.) Instead, we usually use visibility as cosmetic, something that can be collapsed in order to avoid visual clutter, and then expanded for a richer view. (I guess it's another angle where my CGI and not app history trips up a deep understanding of Wicket's; I'm used to a View as being a super thin thing, client side only, whereas I guess Wicket spreads a view-ish layer between HTML and Java, so options like security through visibility make more sense, since much of that is being done on the trusted server not the untrusted client.) Still, yeah, I'd vouch for a isHidden type implementation, and more stressing how isVisibile() causes things not to added. (Heck, I'd like to see isVisible() changed to isAbsent() to really drive home the point ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
I think everybody is missing the point that listview was intended to refresh itself entirely (all the items) on each render not just after a hide/show cycle. The reason for this is that you always want an up-to-date list. If you don't want this this behavior you can use setReuseItems(true); Or am i missing something? Maurice On Sat, May 17, 2008 at 2:28 PM, Kirk Israel [EMAIL PROTECTED] wrote: On Sat, May 17, 2008 at 2:46 AM, Johan Compagner [EMAIL PROTECTED] wrote: Many people expect that is the component is not visible also the models and the data ias not called or touched. Because there state cant be resolved correctly. Still seems a little odd to me. We're adding a component, but we're counting on it not to do anything. Because it's not visible. So it's not really there. But we put it there anyway! Als security is depending on it, it can never be that some thing where security says it is not visible/cant render that is still renders data, this would be a major security hole. OK, this is the first time I've started to hear a reasonable explanations as to why visibility = absence might be useful -- to me it seemed like a pain, with a fair chunk of boilerplate (.setOutputMarkupId(true); and .setOutputMarkupPlaceholderTag(true);) to get things to work correctly, and then unreliability as expectations of a component being ready to go (and not redrawn) aren't met. Part of it is, my main wicket experience hasn't depended on visibility as security; the main app I've been working on doesn't have like a superuser mode, permissions are mostly handled at the API layer and everyone gets about the same view of every screen. (And if I *did* have more user role based components on a single screen, I'd probably consider using a base class, with one subclass being the functional version for people with rights to see it, and one as a placeholder for those who don't.) Instead, we usually use visibility as cosmetic, something that can be collapsed in order to avoid visual clutter, and then expanded for a richer view. (I guess it's another angle where my CGI and not app history trips up a deep understanding of Wicket's; I'm used to a View as being a super thin thing, client side only, whereas I guess Wicket spreads a view-ish layer between HTML and Java, so options like security through visibility make more sense, since much of that is being done on the trusted server not the untrusted client.) Still, yeah, I'd vouch for a isHidden type implementation, and more stressing how isVisibile() causes things not to added. (Heck, I'd like to see isVisible() changed to isAbsent() to really drive home the point ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
On Sat, May 17, 2008 at 5:28 AM, Kirk Israel [EMAIL PROTECTED] wrote: On Sat, May 17, 2008 at 2:46 AM, Johan Compagner [EMAIL PROTECTED] wrote: Many people expect that is the component is not visible also the models and the data ias not called or touched. Because there state cant be resolved correctly. Still seems a little odd to me. We're adding a component, but we're counting on it not to do anything. Because it's not visible. So it's not really there. But we put it there anyway! It is a great facility, really. Consider a search field and a panel that displays results. If there is no search given, you want to hide this panel (which probably also has a border and other visual elements that are only relevant when a search is provided) altogether, and since the panel isn't rendered if implement the hiding by overriding isVisible, you don't have to litter the code of that panel with a dozen null checks, because you know it will only be executed when there is a search term. The same thing /could/ be achieved using component replacement, but for cases like this, that would be way less elegant and more work. Whether 'visible' is the best name... I always found this completely natural, but sure there may be terms to would make more sense to others. Too late for that now, since it's been in Wicket like this from the start :-). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
why is this such a huge discussion? wicket works on markup level - it is a markup generator, so of course visible means whether or not something is visible in the markup. you are free to add whatever it is you want for css/javascript/etc, but it will not be part of core. we give you enough flexibility to build whatever it is you want to build. its just like desktop frameworks, when you set something invisible it isnt actually there, its not like it just has a zindex below the main window... -igor On Sat, May 17, 2008 at 10:22 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Sat, May 17, 2008 at 5:28 AM, Kirk Israel [EMAIL PROTECTED] wrote: On Sat, May 17, 2008 at 2:46 AM, Johan Compagner [EMAIL PROTECTED] wrote: Many people expect that is the component is not visible also the models and the data ias not called or touched. Because there state cant be resolved correctly. Still seems a little odd to me. We're adding a component, but we're counting on it not to do anything. Because it's not visible. So it's not really there. But we put it there anyway! It is a great facility, really. Consider a search field and a panel that displays results. If there is no search given, you want to hide this panel (which probably also has a border and other visual elements that are only relevant when a search is provided) altogether, and since the panel isn't rendered if implement the hiding by overriding isVisible, you don't have to litter the code of that panel with a dozen null checks, because you know it will only be executed when there is a search term. The same thing /could/ be achieved using component replacement, but for cases like this, that would be way less elegant and more work. Whether 'visible' is the best name... I always found this completely natural, but sure there may be terms to would make more sense to others. Too late for that now, since it's been in Wicket like this from the start :-). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
You should use isVisible when possible. The notion of component's visibility has to do with whether the component renderers or not. So yes, the list will be reconstructed from scratch. If you're doing something Ajaxy, this might not be what you want. I personally wish that the Ajax implementation was a bit more automatic by default. Adding a behavior for Ajax to a component could easily set the right flags since this is the most common case. People who are doing custom ID management could turn off the automatic default. I usually look for places to handle this kind of thing centrally, whether it's some component base class or a base behavior class or a custom behavior. Once you've defined a component that's good for your application, you just repeat use of it. Kirk Israel-2 wrote: If I have a component with a nested ListView, and I make the parent component go away for a bit with setVisible, the List will be reconstructed from scratch? Is the understanding that for Wicket Invisible means the component objects (Labels, etc) have Gone Away? What are the advantages of that? I know it means there's a lot of boilerplate that has to be done for the opposite, when something starts out as Visible false, the old .setOutputMarkupId(true); and .setOutputMarkupPlaceholderTag(true); I think it's part of the philosophy of Wicket I don't get yet... If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Visibility-vs.-CSS-visibility-tp17285530p17286015.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
On Fri, May 16, 2008 at 7:34 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). I'm still not comfortable with is it visible being mixed up with is it plain gone... Here was my scenario, I'll tell you my error, the fix, and then I'd love to hear if there's a better way. Essentially we have a form where you can select countries, and we want to offer two different views, a flat list collection of checkboxes for all countries, and then a series of lists broken out by continent -- two checkgroups w/ the same underlying model. For screen realestate reasons, the CheckGroups live in scrollable Divs, and the Checks live in a special ListView thing. So far so good. Then each of the Continents has a little summary part, a textual description of what's selected (the idea is the comma separated summary is always visible vs. the checks which might be scrolled away, and the summary can be clever and concise and say ALL EUROPE except France, Spain) So - and I know this is a little bit of an anti-pattern - as I built each Continent I added the Summary label, and then kept a member variable list of those around, and then had the checkboxes (whether on the flat list or the by-continent list) call a function to add the summaries to the Ajax request target. What I didn't realize, when I made the by-continent view not visible and the flat list visible, and then back, the Continents actually got regenerated, with new Summary labels, and so the List was full of stale label referenes that barfed when I tried to update them. I know it's not encouraged to keep member variables of page components around, but I couldn't think of another way of getting to them... The net-net is, it seems very odd to me that merely switching around visibility should invalidate object references, that the complexity in actually USING the visibility outweighs the efficiency for free, and I wish I had a simple render this, but set its CSS visibility to hidden switch without having to go and manually modify attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
Again, you probably shouldn't be setting state like this, and you can create a generic hiding behavior for now that should solve most of your problems. All that is at stake here is really just convenience, not the programming model. On the other hand, this is a very common problem so it might be worth discussing adding a generic solution to component like set/isHidden(). The implementation would be slightly tricky and would require two more flag bits, but we could detect whether isHidden was overridden in component and delegate to some kind of singleton behavior. I haven't thought this through very far, but you should feel free to open a JIRA issue for this feature request. Kirk Israel-2 wrote: On Fri, May 16, 2008 at 7:34 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). I'm still not comfortable with is it visible being mixed up with is it plain gone... Here was my scenario, I'll tell you my error, the fix, and then I'd love to hear if there's a better way. Essentially we have a form where you can select countries, and we want to offer two different views, a flat list collection of checkboxes for all countries, and then a series of lists broken out by continent -- two checkgroups w/ the same underlying model. For screen realestate reasons, the CheckGroups live in scrollable Divs, and the Checks live in a special ListView thing. So far so good. Then each of the Continents has a little summary part, a textual description of what's selected (the idea is the comma separated summary is always visible vs. the checks which might be scrolled away, and the summary can be clever and concise and say ALL EUROPE except France, Spain) So - and I know this is a little bit of an anti-pattern - as I built each Continent I added the Summary label, and then kept a member variable list of those around, and then had the checkboxes (whether on the flat list or the by-continent list) call a function to add the summaries to the Ajax request target. What I didn't realize, when I made the by-continent view not visible and the flat list visible, and then back, the Continents actually got regenerated, with new Summary labels, and so the List was full of stale label referenes that barfed when I tried to update them. I know it's not encouraged to keep member variables of page components around, but I couldn't think of another way of getting to them... The net-net is, it seems very odd to me that merely switching around visibility should invalidate object references, that the complexity in actually USING the visibility outweighs the efficiency for free, and I wish I had a simple render this, but set its CSS visibility to hidden switch without having to go and manually modify attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Visibility-vs.-CSS-visibility-tp17285530p17287030.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
Of course there are many good counterarguments to this. There are already a lot of methods in Component, you can do this without any changes and it may be confusing to have a concept of hidden on top of the existing visible concept. Jonathan Locke wrote: Again, you probably shouldn't be setting state like this, and you can create a generic hiding behavior for now that should solve most of your problems. All that is at stake here is really just convenience, not the programming model. On the other hand, this is a very common problem so it might be worth discussing adding a generic solution to component like set/isHidden(). The implementation would be slightly tricky and would require two more flag bits, but we could detect whether isHidden was overridden in component and delegate to some kind of singleton behavior. I haven't thought this through very far, but you should feel free to open a JIRA issue for this feature request. Kirk Israel-2 wrote: On Fri, May 16, 2008 at 7:34 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). I'm still not comfortable with is it visible being mixed up with is it plain gone... Here was my scenario, I'll tell you my error, the fix, and then I'd love to hear if there's a better way. Essentially we have a form where you can select countries, and we want to offer two different views, a flat list collection of checkboxes for all countries, and then a series of lists broken out by continent -- two checkgroups w/ the same underlying model. For screen realestate reasons, the CheckGroups live in scrollable Divs, and the Checks live in a special ListView thing. So far so good. Then each of the Continents has a little summary part, a textual description of what's selected (the idea is the comma separated summary is always visible vs. the checks which might be scrolled away, and the summary can be clever and concise and say ALL EUROPE except France, Spain) So - and I know this is a little bit of an anti-pattern - as I built each Continent I added the Summary label, and then kept a member variable list of those around, and then had the checkboxes (whether on the flat list or the by-continent list) call a function to add the summaries to the Ajax request target. What I didn't realize, when I made the by-continent view not visible and the flat list visible, and then back, the Continents actually got regenerated, with new Summary labels, and so the List was full of stale label referenes that barfed when I tried to update them. I know it's not encouraged to keep member variables of page components around, but I couldn't think of another way of getting to them... The net-net is, it seems very odd to me that merely switching around visibility should invalidate object references, that the complexity in actually USING the visibility outweighs the efficiency for free, and I wish I had a simple render this, but set its CSS visibility to hidden switch without having to go and manually modify attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Visibility-vs.-CSS-visibility-tp17285530p17287068.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Visibility vs. CSS visibility
by the way, don't forget that behaviors are reusable components too. there can be advantages to encapsulating your hiding/showing logic in a behavior. this can actually lead to less of this manual manipulation you're talking about than the solution you seem to want. and because the logic is encapsulated, it can work like a mix-in work where components don't need to be aware of how they are being hidden and shown. this kind of decoupling can actually be a big advantage for many problems over a simple set/isHidden approach, which ties the component's visibility to logic embedded in the component. i would step back and think about how you might use behaviors here before jumping to conclusions. Jonathan Locke wrote: Of course there are many good counterarguments to this. There are already a lot of methods in Component, you can do this without any changes and it may be confusing to have a concept of hidden on top of the existing visible concept. Jonathan Locke wrote: Again, you probably shouldn't be setting state like this, and you can create a generic hiding behavior for now that should solve most of your problems. All that is at stake here is really just convenience, not the programming model. On the other hand, this is a very common problem so it might be worth discussing adding a generic solution to component like set/isHidden(). The implementation would be slightly tricky and would require two more flag bits, but we could detect whether isHidden was overridden in component and delegate to some kind of singleton behavior. I haven't thought this through very far, but you should feel free to open a JIRA issue for this feature request. Kirk Israel-2 wrote: On Fri, May 16, 2008 at 7:34 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: If you wanted to just a cosmetic, DHTM/CSS display: none type of visibility, is there something you can do other than making a new AttributeModifier (with a custom Visibility Model kind of thing) or a SimplleAttributeModifier with a CSS display:none String there? Well, if the component isn't visible (I typically override isVisible, because there's typically an algorithm that determines whether the component is visible), no rendering is done at all, which can save things like database roundtrips if that component or it's children use that, and it also often lets you avoid having to do null checks and stuff in your models (e.g. you can depend on a model function only to be executed when another object - the one that determines whether the component is visible - is checked). I'm still not comfortable with is it visible being mixed up with is it plain gone... Here was my scenario, I'll tell you my error, the fix, and then I'd love to hear if there's a better way. Essentially we have a form where you can select countries, and we want to offer two different views, a flat list collection of checkboxes for all countries, and then a series of lists broken out by continent -- two checkgroups w/ the same underlying model. For screen realestate reasons, the CheckGroups live in scrollable Divs, and the Checks live in a special ListView thing. So far so good. Then each of the Continents has a little summary part, a textual description of what's selected (the idea is the comma separated summary is always visible vs. the checks which might be scrolled away, and the summary can be clever and concise and say ALL EUROPE except France, Spain) So - and I know this is a little bit of an anti-pattern - as I built each Continent I added the Summary label, and then kept a member variable list of those around, and then had the checkboxes (whether on the flat list or the by-continent list) call a function to add the summaries to the Ajax request target. What I didn't realize, when I made the by-continent view not visible and the flat list visible, and then back, the Continents actually got regenerated, with new Summary labels, and so the List was full of stale label referenes that barfed when I tried to update them. I know it's not encouraged to keep member variables of page components around, but I couldn't think of another way of getting to them... The net-net is, it seems very odd to me that merely switching around visibility should invalidate object references, that the complexity in actually USING the visibility outweighs the efficiency for free, and I wish I had a simple render this, but set its CSS visibility to hidden switch without having to go and manually modify attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Visibility-vs.-CSS-visibility-tp17285530p17287367.html Sent from the Wicket - User mailing list archive at Nabble.com. - To
