generalized way to ignore mouse input during screen refresh?
So one problem we've seen in a few places occurs when a (somewhat slow) request happens that refreshes the page or component, but then the user clicks on a link on the pre-refresh screen, and ends up getting a nasty exception thrown, since the component clicked on no longer exists Is there a single, easy workaround for this? Obviously you can try to limit the situations where this occurs, like my redrawing as little as possible, or otherwise making things less time consuming, but it still seems like it would be good if there was a general mechanism for ignoring inputs once some kind of Ajaxy-process is started... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
any better at dealing with Image in DataTable
Running into the same issue as seen in: http://www.mail-archive.com/wicket-u...@lists.sourceforge.net/msg03706.html where you try to put an Image in a DataTable and get Component cell must be applied to a tag of type 'img', not 'span wicket:id=cell' (line 0, column 0) Is there a simpler way of handling this thats emerged in the 3 years since, or do you still need at least an inner class with a standalone HTML file? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
are checkboxes broken WAS: missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
OK, to summarize what came previously:
we had a palette control (two parallel listboxes, with push buttons
in between for moving items from one list to the other), and tried to
have a checkbox that would select all - that part worked fine, but
for some reason we couldn't get it so using the buttons to remove
items from the right list would also cause the select all checkbox
to be unchecked. We punted, and used a select all link that didn't
need to be visually updated.
But now we're seeing some kind of related problem... in this form we
have a big CheckGroup -- (previously we had trouble getting the
contents of the CheckGroup to update when they weren't DHTML-visible,
so we redraw the whole panel the checkboxes are on). Individual
subsets of the checkboxes in the overall checkgroup have their own
select all and clear links, along with a written summary of what
is selected inside that checkgroup.
Now, when someone clicks the push button in the pallet control, the
select all links for the checkgroup subsets seem to be updating the
model (since we see the written summary labels update) but the
checkboxes don't check! -- until you click one of the checkboxes in
ANY of the check group subsets, then the select all links can update
the checkboxes as well.
By using labels w/ timestamps, it seems clear that everything is being
redrawn. And even if all the internal logic for the palette control
pushbutton is removed, it's just a AjaxFallbackButton with
setDefaultFormProcessing(false) that does nothing, the select all
links can no longer make the checkboxes show the correct state of
their entry in the cjeckgroup, even as they're redrawn. (Until one is
clicked, at which point the connection is restored)
So what is going on here? Does this symptom seem to point to
something we're doing wrong, or is there some kind of generalized
checkbox updating issue? (since this is KIND of like the previous
problem)
This is Wicket 1.3.3...
On Tue, May 27, 2008 at 9:15 AM, Kirk Israel [EMAIL PROTECTED] wrote:
The Model was a HashMapString,Boolean.
When the page was first loaded, only true values were loaded into
it, i.e. there were no keys or values for checkboxes that weren't
supposed to be checked.
Later, it didn't matter if we added in an explicit false value for a
key, or removing the key, neither were enough to get the checkbox to
read that its value had changed.
On Sun, May 25, 2008 at 6:00 AM, Thomas Mäder [EMAIL PROTECTED] wrote:
What value are you returning from the model? In CheckBox.java, I find this:
final String value = getValue();
if (value != null)
{
try
{
if (Strings.isTrue(value))
{
tag.put(checked, checked);
}
And Strings.isTrue() only accepts a bunch of well known values (plus null)
Thomas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
the left/right moves ARE being done in the buttons onSubmit, I was hoping calling .setDefaultFormProcessing(false); when adding the button to the page would have prevented that? On Fri, May 23, 2008 at 4:50 AM, Thomas Mäder [EMAIL PROTECTED] wrote: Do the move left/move right controls do a submit? If so you might also be resubmitting the (old) check box value. Thomas We have a list view that iterates over manufacturers, and each manufacturer has a pallet control of devices (two list boxes w/ move selection to right list, move selection to left list buttons between) along with a all for manufacturer checkbox - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
According to The PropertyModel javadoc refers to the PropertyResolver javadoc which says This can can then be a bean property with get and set method. Or if a map is given as an object it will be lookup with the property as a key when there is not get method for that property. -- http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/util/lang/PropertyResolver.html given that it more or less works except when I'm trying to change the value, it's not the #1 suspect right now.. On Fri, May 23, 2008 at 10:33 AM, Thomas Mäder [EMAIL PROTECTED] wrote: I would think so, too. I was looking more closely at your code, and this seems fishy: new PropertyModel(mTargetModel.getManufacturersAsMap(), manufacturerName)) as I understand it, PropertyModel doesn't work with Maps, does it? It works on Java Beans. Thomas On Fri, May 23, 2008 at 3:16 PM, Kirk Israel [EMAIL PROTECTED] wrote: the left/right moves ARE being done in the buttons onSubmit, I was hoping calling .setDefaultFormProcessing(false); when adding the button to the page would have prevented that? On Fri, May 23, 2008 at 4:50 AM, Thomas Mäder [EMAIL PROTECTED] wrote: Do the move left/move right controls do a submit? If so you might also be resubmitting the (old) check box value. Thomas We have a list view that iterates over manufacturers, and each manufacturer has a pallet control of devices (two list boxes w/ move selection to right list, move selection to left list buttons between) along with a all for manufacturer checkbox - 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: missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
So these pallet controls are inside of a ListView that is ultimately nested in a Form. I *want* the button to do it's stuff of moving things from one list to the other, and unsetting the checkbox-- I don't want it to do any other kind of form processing. It was suggested maybe the checkbox value is being re-entered as part of the form of the button, but A. I would hope that .setDefaultFormProcessing(false) would have prevented that, and B. it doesn't seem like the Model's accessor for the hashmap for this checkbox is being accessed, as it is when I click on the checkbox directly. In short, the problem seems to be that the Checkbox is being redrawn, but not checking its underlying PropertyModel to do so, so its state is not correctly updated. It's not clear to me where Wicket is then getting the information to redraw... it's like it's caching it somewhere. (Again, I think I know it's being redrawn because I put inside a span and am redrawing that, and I put a label on the span that gets the current timestamp, and I can see THAT updating with each click...) On Fri, May 23, 2008 at 12:51 PM, Thijs Vonk [EMAIL PROTECTED] wrote: I'm not sure what you are saying here. But if it is what I'm thinking then you have misunderstood the meaning of .setDefaultFormProcessing. If your component is in a form, the 'defaultFormProcessing' will try to write any changes in the form to the model, and then call the onSubmit of the form, and finally the onSubmit of the button. If set to false it will skip all the form handling and call the onSubmit of the button directly. http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/markup/html/form/Button.html#setDefaultFormProcessing(boolean) So if you are doing anything in the buttons 'onSubmit' that you don't want in certain cases, then calling setDefaultFormProcessing(false) won't have any affect. Thijs Kirk Israel wrote: the left/right moves ARE being done in the buttons onSubmit, I was hoping calling .setDefaultFormProcessing(false); when adding the button to the page would have prevented that? On Fri, May 23, 2008 at 4:50 AM, Thomas Mäder [EMAIL PROTECTED] wrote: Do the move left/move right controls do a submit? If so you might also be resubmitting the (old) check box value. Thomas We have a list view that iterates over manufacturers, and each manufacturer has a pallet control of devices (two list boxes w/ move selection to right list, move selection to left list buttons between) along with a all for manufacturer checkbox - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
missing something: getting AjaxCheckBox to recheck value from model as its redrawn?
Short version of my question:
Why wouldn't redrawing a surrounding span for an AjaxCheckBox (all
embedded inside a ListView) be enough to get it to check its
underlying PropertyModel, and then reflect that new value?
(and is it broken for an underlying PropertyModel's hashmap to return
null for that key?)
Background:
So I'm tearing my hair out over this, because I've (somewhat) deeply
researched what's going on our code side, but might be dumbly missing
something basic on the Wicket side.
We have a list view that iterates over manufacturers, and each
manufacturer has a pallet control of devices
(two list boxes w/ move selection to right list, move selection to
left list buttons between) along with a all for manufacturer
checkbox
(the checkbox is a bit tricky, because it's also saying this is true
for this manufacturer even if it's not a device we recognize)
When you click the select all checkbox, it calls the function that
moves everything into the right hand select list, great.
What I'd like to have happen is moving an item from the right hand
list back to the left also unchecks the select box.
I cannot get this checkbox to update for anything!
Another developer has the underlying model contain a
HashMapString,Boolean of manufacturers, so the code is like
final AjaxCheckBox selectAllCheckbox = new
AjaxCheckBox(manufacturerCheckbox, new
PropertyModel(mTargetModel.getManufacturersAsMap(), manufacturerName))
{
then, when the remove from right list button is hit, it removes the
manufacturer value from the list (originally it just set it to false;
is it ok to have the Property return null for a checkbox value, to
mean false?) and then adds the checkbox to the AjaxRequestTarget ;
actually it adds a containing span, which also (for now) has a label
w/ a timestamp, so I can see that the whole span containing the
checkbox is being redrawn.
I also updated the Target Model's getManufacturersAsMap() function, so
that it logs when it's called. Oddly (to me, again I might be missing
something here) the getManufacturersAsMap() is called when the page is
constructed and when the checkbox is clicked but NOT when the span
including the checkbox is being redrawn.
Just out of curiosity I've tried this with and without the ListView
setReuseItems set to true. I've made sure that appropriate
setOutputMarkupIds are set (it seems some of the rules for making sure
your nesting wicket:id hierarchy are relaxed in the case of ListViews,
though of course I try to be as faithful as always, still that doesn't
seem to be the problem)
-
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]
Wicket Visibility vs. CSS visibility
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]
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]
overriding the shift/ctrl in shift-click
Inside of a Modal Window, I have a Panel with a Fragment that has AjaxFallbackLink that we use for indicating selection. (The onClick toggles a selection status in the underlying model) The trouble is a shift or ctrl click opens up a new window or tab with an Internal Error showing- ideally we'd capture the shift or click state so we can do the UI appropriate thing, but for now, is there any easy way of treating a shift or ctrl click as a normal click? I know this (the shift- and ctrl- behavior) might be browser specific and happening at a low level, but I'm trying to find a workaround without revamping the whole structure of what I'm working with... Thanks!
Re: suggesting alternative to IndicatingAjaxFallbackLink-class for just changing pointer/cursor
Unfortunately the approach below seems not to work reliably on IE7;
for certain kind of changes, the OnSuccess or OnFailure never gets
called and so the cursor gets stuck in Busy mode. That stinks!
On Dec 18, 2007 11:29 AM, Kirk Israel [EMAIL PROTECTED] wrote:
I guess I prefer the convention of changing the mouse pointer to
busy rather than putting a little throbber by the link for two
reasons:
1. the throbber risks messing with the layout of the page
2. Changing the cursor has a much longer history as a UI convention
for computer busyness
Now Firefox was already changing the cursor for Ajax operations for
some cases, but it was inconsistent,
I think this small class deals with that:
/**
* AjaxFallbackLink that changes mouse pointer to progress (i.e.
busy) during Ajax operations
* for the link itself (in case the pointer is still hovering over it)
and the whole document
* (if the pointer has been moved)
*
*/
public abstract class ProgressPointerAjaxFallbackLink extends
AjaxFallbackLink {
public ProgressPointerAjaxFallbackLink(final String id) {
this(id, null);
}
public ProgressPointerAjaxFallbackLink(final String id, final IModel
model){
super(id, model);
}
@Override
protected IAjaxCallDecorator getAjaxCallDecorator() {
return new AjaxCallDecorator(){
private static final long serialVersionUID = 1L;
public CharSequence decorateScript(CharSequence pScript) {
return
this.style.cursor='progress';document.body.style.cursor='progress';+pScript;
}
public CharSequence decorateOnSuccessScript(CharSequence pScript)
{
return
this.style.cursor='pointer';document.body.style.cursor='auto';+pScript;
}
public CharSequence decorateOnFailureScript(CharSequence pScript)
{
return
this.style.cursor='pointer';document.body.style.cursor='auto';+pScript;
}
};
}
}
ProgressPointerAjaxFallbackLink is more concise but probably less
readable than my coworker's suggestion BusyCursorAjaxFallbackLink.
Actually I might switch to the latter.
Feedback to this approach and/or implementation welcome.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
IE7, loose.dtd, and the default Wicket error pages
So IE7 seems to choke on the default Wicket error pages (such as time out) because it doesn't like the --s inside of http://www.w3.org/TR/html4/loose.dtd Our work around was to override the pages on a case per case basis: getApplicationSettings().setPageExpiredErrorPage(TimeoutPage.class); I don't know if there's fingerpointing of IE7 vs w3.org about this. Being a pragmatic developer with street roots, I greatly dislike a decent error page with a link to the front of the site being replaced with an ugly can't parse the XML page, so I was wondering who will bend first, IE7, w3.org, or Wicket? And is there another more generalized solution to this problem? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ModalWindow: open on page construction
Is there a way to get a ModalWindow to open up along with its underlying page? The usual show() takes an AjaxRequestTarget ... I have at least one work around in mind (ripping out the ModalWindow into a separate object so the launching page could show it too) but it would be more elegant to just modify the constructor so that it takes a boolean causing the page to start with the dialog... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ModalWindow: open on page construction
(Sorry, I should have added I found the September discussion, I wondered if there was a more elegant solution in the meanwhile...) On Nov 16, 2007 11:45 AM, Kirk Israel [EMAIL PROTECTED] wrote: Is there a way to get a ModalWindow to open up along with its underlying page? The usual show() takes an AjaxRequestTarget ... I have at least one work around in mind (ripping out the ModalWindow into a separate object so the launching page could show it too) but it would be more elegant to just modify the constructor so that it takes a boolean causing the page to start with the dialog... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating components on Page from ModalWindow's internal Page's components
I'm still having the fundamental problem of an Image refusing to update. (A coworker suggested that it might be that I wasn't (yet) updating the underlying model that the page was drawing from, which didn't smell like the problem to me, since I could see the component-based updating I thought I was doing, but I put in that change of updating the model, but still I can NOT get the image part of the page to update.) The Label subcomponent of the component is updating fine, but, the ImageComponent (a wrapper to a Wicket Image) seems as fix'd as the north star. I'm working with my own MediaComponent class. It has one of our ImageComponent, added thus: mImageComponent = new ImageComponent(mediaimage,mResource,pClassStyle); mImageComponent.setOutputMarkupId(true); add(mImageComponent); (the mResource here is our MMSDataResource which extends Wicket's DynamicImageResource ) Then when it comes time to update w/ the MMSDataResource passed back from the ModalWindow, I do this: ImageComponent newImageComponent = new ImageComponent(mediaimage,mResource,mClassStyle); newImageComponent.setOutputMarkupId(true); mImageComponent.replaceWith(newImageComponent); mImageComponent = newImageComponent; pTarget.addComponent(MediaPanel.this); i can add a pTarget.addComponent(mImageComponent); to no avail; if I put it before the swap so the reference is to the old mImageComponent, it rightly complains, and doesn't make a difference coming later... I think adding the MediaPanel itself means the imageComponent inside of it gets redrawn via Ajax too. So I see that MMSDataResource's getImageData() is NOT being called by DynamicImageResource for the Ajax re-render. I see the whole MediaPanel getting redrawn in the Ajax debug window, but apparently the Image reference from ImageComponent is the same old thing. I know there are a few places in my group's code that I might be the actual source of the problem, but can anyone see if I'm doing something wrong? Can't you swap in a new subcomponent during an AjaxRequestTarget-driven update? Is there a likely culprit, or something else that needs to be explicitly added to the AjaxRequestTarget ? Thanks... Kirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating components on Page from ModalWindow's internal Page's components
This might well be the problem. How do you explicitly postpend something to the URL of a Wicket Image? The URLs we've been using are autogenerated, and my Google mojo is failing me... it doesn't have anything to do with .forURL(), does it? On 10/29/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Not sure if it is relevant, but to update images using ajax you need to generate a unique URL by adding a timestamp or random number to it. Martijn On 10/29/07, Kirk Israel [EMAIL PROTECTED] wrote: I'm still having the fundamental problem of an Image refusing to update. (A coworker suggested that it might be that I wasn't (yet) updating the underlying model that the page was drawing from, which didn't smell like the problem to me, since I could see the component-based updating I thought I was doing, but I put in that change of updating the model, but still I can NOT get the image part of the page to update.) The Label subcomponent of the component is updating fine, but, the ImageComponent (a wrapper to a Wicket Image) seems as fix'd as the north star. I'm working with my own MediaComponent class. It has one of our ImageComponent, added thus: mImageComponent = new ImageComponent(mediaimage,mResource,pClassStyle); mImageComponent.setOutputMarkupId(true); add(mImageComponent); (the mResource here is our MMSDataResource which extends Wicket's DynamicImageResource ) Then when it comes time to update w/ the MMSDataResource passed back from the ModalWindow, I do this: ImageComponent newImageComponent = new ImageComponent(mediaimage,mResource,mClassStyle); newImageComponent.setOutputMarkupId(true); mImageComponent.replaceWith(newImageComponent); mImageComponent = newImageComponent; pTarget.addComponent(MediaPanel.this); i can add a pTarget.addComponent(mImageComponent); to no avail; if I put it before the swap so the reference is to the old mImageComponent, it rightly complains, and doesn't make a difference coming later... I think adding the MediaPanel itself means the imageComponent inside of it gets redrawn via Ajax too. So I see that MMSDataResource's getImageData() is NOT being called by DynamicImageResource for the Ajax re-render. I see the whole MediaPanel getting redrawn in the Ajax debug window, but apparently the Image reference from ImageComponent is the same old thing. I know there are a few places in my group's code that I might be the actual source of the problem, but can anyone see if I'm doing something wrong? Can't you swap in a new subcomponent during an AjaxRequestTarget-driven update? Is there a likely culprit, or something else that needs to be explicitly added to the AjaxRequestTarget ? Thanks... Kirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ - 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: updating components on Page from ModalWindow's internal Page's components
I came to a similar conclusion shortly before reading this. So now I seem to be updating in the correct place, but I'm having trouble getting the image component to swap out within the onClose(AjaxRequestTarget pTarget) Inside the ModalWindow, assuming I previously did a setOutputMarkupId on the original component, something like this works: Component newComponent = new Component(); origComponent.replaceWith(newComponent); origComponent = newComponent; Should I be able to do something similar inside the onClose, and get Ajax to replace the component? I add both the old and the new object to the AjaxRequestTarget w/ addComponent, but it doesn't seem to be updating properly... On 10/23/07, Matej Knopp [EMAIL PROTECTED] wrote: Problem is that AjaxRequestTarget only applies to one page. If you want to update the outer page (assuming that you have another page inside modal window, not a panel), the only way to do it is from within WindowClosedCallback registered to modal window. So you have to mark somehow dirty components on parent page and then update those when modal window closes. -Matej On 10/23/07, Kirk Israel [EMAIL PROTECTED] wrote: So I spoke too soon about this working out... I think the core problem is kind of simple: How can a component of a page inside a ModalWindow update components on the page that holds the Modal Window? More Specifically: I have an EditCreativePage that creates an instance of UploadMediaPanelPage, then creates a ModalWindow with a createPage() that gets the instance of the UploadMediaPanelPage. EditCreativePage has a MediaPanel that has a link that sets a callback inside of UploadMediaPanelPage and calls the ModalWindow.show() UploadMediaPanelPage has an upload Form, whose onSubmit seems to do a fine job of parsing data of the uploaded image, and shows a preview panel w/ the image etc. UploadMediaPanelPage also has its own AjaxLinks for Ok and Cancel - when I pass the AjaxRequestTarget the onClick for OK gets back to the MediaPanel, and it tries to update itself and its embedded ImageComponent. Now, when I forget to call MediaPanel.setOutputMarkupId(true), the ModalWindow shows the exception java.lang.IllegalArgumentException: cannot update component that does not have setOutputMarkupId property set to true. when I do call MediaPanel.setOutputMarkupId(true), there's no exception, but the Ajax Debug window *inside the ModalWindow* shows something like ERROR: Component with id [[mediaimage40]] a was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. and nothing shows up in th Ajax Debug of EditCreativePage, which is probably the problem... Is there a work around for this? Either direct, or do I need to somehow override the ModalWindow setWindowClosedCallback ? But in that case, what do I use for an AjaxRequestTarget ? Thanks for any help... - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
retrieving page from ModalWindow's setPageCreator(ModalWindow.PageCreator)
I looked at the JavaDoc and inspected the class, but couldn't find a clear way of getting the page I'm generating in ModalWindow.setPageCreator's createPage() out of the ModalWindow. (My situation is a little complex: I want a single upload image ModalWindow (and corresponding page embedded in that, I think it has to be a page so that I can use the Upload tag properly) for the entire parent page. And then components of the parent page .show() the ModalWindow after passing themselves into its embedded page, so that the embedded page can call them back with the data the user uploaded.) It's not a blocking issue, because createPage() is being defined inside the parentPage, and I can set a reference to the new page, but it means the parentPage has to expose two seperate elements: the ModalWindow itself, so it can be show()'d, and the embedded Page, so the Page's callback function can be set. So, is there an obvious way of doing this that I missed? I see there's a getPage() function but that seems to be the basic Component implementation of it. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
updating components on Page from ModalWindow's internal Page's components
So I spoke too soon about this working out... I think the core problem is kind of simple: How can a component of a page inside a ModalWindow update components on the page that holds the Modal Window? More Specifically: I have an EditCreativePage that creates an instance of UploadMediaPanelPage, then creates a ModalWindow with a createPage() that gets the instance of the UploadMediaPanelPage. EditCreativePage has a MediaPanel that has a link that sets a callback inside of UploadMediaPanelPage and calls the ModalWindow.show() UploadMediaPanelPage has an upload Form, whose onSubmit seems to do a fine job of parsing data of the uploaded image, and shows a preview panel w/ the image etc. UploadMediaPanelPage also has its own AjaxLinks for Ok and Cancel - when I pass the AjaxRequestTarget the onClick for OK gets back to the MediaPanel, and it tries to update itself and its embedded ImageComponent. Now, when I forget to call MediaPanel.setOutputMarkupId(true), the ModalWindow shows the exception java.lang.IllegalArgumentException: cannot update component that does not have setOutputMarkupId property set to true. when I do call MediaPanel.setOutputMarkupId(true), there's no exception, but the Ajax Debug window *inside the ModalWindow* shows something like ERROR: Component with id [[mediaimage40]] a was not found while trying to perform markup update. Make sure you called component.setOutputMarkupId(true) on the component whose markup you are trying to update. and nothing shows up in th Ajax Debug of EditCreativePage, which is probably the problem... Is there a work around for this? Either direct, or do I need to somehow override the ModalWindow setWindowClosedCallback ? But in that case, what do I use for an AjaxRequestTarget ? Thanks for any help... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket visibility and Panel positioning
I looked over a lot of the usual examples but didn't quite find what I
was looking for... I also tried looking for more information inside of
Pro Wicket. As always, pointers to useful examples and documentation
appreciated.
My overall task is to make a dropdown menu, one that appears under a
graphical More Ajax Link, some kind of Panel containing clickable
links.
First question on visibility: in the Java i had something like
moreMenuPanel = new WebMarkupContainer(moreMenu);
moreMenuPanel.setVisible(false);
moreMenuPanel.setOutputMarkupId(true);
add(moreMenuPanel);
against html
div wicket:id=moreMenuHey there/div
And then there was an AjaxFallbackLink with
public void onClick(AjaxRequestTarget ajaxTarget) {
moreMenuPanel.setVisible(true);
ajaxTarget.addComponent(moreMenuPanel);
}
This didn't do what i expected, the panel didn't appear. The Ajax console shows
ERROR: Component with id [[moreMenu72]] a was not found while trying
to perform markup update. Make sure you called
component.setOutputMarkupId(true) on the component whose markup you
are trying to update.
Is the initial invisibility messing things up? I think I've heard that
Wicket will sometimes not display any markup for things where
isVisible is false? Though in this case in the page source I see
div id=moreMenu72Hey there/div
We have a work around of having an AttributeModifier to set the
visibility, but it seems rather crude... or am i missing the point of
how visibility is used in Wicket?
And once that's solved, there's still the problem of positioning...
ideally this panel is floating, and can be passed a component on the
Java that will determine where it appears. Is this something that
needs to be built from a fairly low level w/ behaviors and custom
javascript, or is there something closer to ready to go?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
On 8/31/07, Scott Swank [EMAIL PROTECTED] wrote:
I will not argue against Lisp. The paucity of Lisp/Scheme/Haskell
within professional software development is criminal. That is why,
for example, we will be seeing continuations in Java 7.
Heh, even though the idea goes so far, that reminds me of the hint of
Lisp that lives in Perl's list/array syntax, i.e. $foo =
(bar,baz);
That then reminds me of an odd syntax asymmetry in mostly all (I think
Algol-derived, though I may be getting that wrong, in practice I
tend to think of it as C-derived) languages: functions take multiple
arguments but return a single value... sometimes I wish I could do
something like Perl's
($foo,$bar,$baz) = func();
sub func{
return (1,2,3);
}
in Java. Maybe though my reluctance to, say, write a class the solely
exists as a bundler / wrapper class for the multiple values I would
want to return ties into my lack of grace in turning to inner
classes... one-off classes feels a bit like needlessly multiplying
entities, and while as Igor points out reusable-ness is at best a
happy by-product of good OO, it's so often touted and taught as a
benefit that I have trouble shaking that feeling.
I confess, with the academic Lisp I've had, I have a hard time
grasping how you would do many simple tasks within the paradigm (and
not shoehorning the mentality of other languages into the syntax.) I'm
always worried I'll end up with something like my brief academic stint
with Prolog, the assigment was, given basic parent/child relationship
definitions, construct rules for determining grandparent/aunt/uncles
etc. The core of it was easy enough, but the best the professor (whom
I admire greatly) could come up with to weed out duplicates was an
ungainly, procedural-looking hack.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
Wicket is not for newbie OOP developers. We don't pretend that it is. That was never the goal. You need rather solid OO skills to get Wicket. But if you want to learn, I think Wicket is a pretty good material. I'm going to go out on a limb - because I'm sure there are plenty of anecdotal exceptions, and maybe it'll sound too defensive anyway - that it's not just pure OO skills that come in useful to bring to the Wicket party, but expereince with OO UI Skills, and specifically Swing. An interesting concept in thinking about Model 2+, homegrown approaches is how Ajax and DHTM change things. One option new browser technologies are allowing is MUCH of the work to be moved to the client, with HTTP only being used when storing things on the server or at least in the session. So your scenario of multifaceted, stateful things would really need a good ponder for me to consider how I'd do that in HTTP-centric approaches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
On 8/31/07, Scott Swank [EMAIL PROTECTED] wrote: That is why flat, page/request granularity web UI frameworks have succeeded. They are simple and procedural. The reason that languages such as Smalltalk, Java C# are much better than languages such as Fortan, Pascal and C is that the former have a range of syntax, objects, that their procedural predecessors lack. I want to hear you argue with the people who feel Lisp (Paul Graham among them) is horribly under-represented in software development outside of Academia. (The trouble with Lisp (at least as it was taught in Princeton-program based Universities in the early 90s) is that, like a lot of languages, you tend to judge it on its common APIs and libraries, and for many students that's just a primitive little command loop with primitive file I/O at best.) And I swear, I'm trying to learn here, and not pick fights. I'm also trying to not let me sometimes working out of my comfort zone make me highly defensive or judgemental. So let me play devil's advocate here: You said flat, page/request granularity web UI frameworks have succeeded. They are simple and procedural. Simplicity is often regarded as a good thing. Probably, it is, in of itself, a good thing: the problem then occurs where you try to use the simple methods on problems they go beyond their scope. CGI-centric approaches offer some beautifully simple concepts, a pretty hammer that (I'd say) may well be right for many programming situations: a simple key/value map for input, another key/value map for storing things on a session, output as text that the browser will interpret and turn into screen elements. This may even map well to how civilians see the web. (as opposed to a desktop app). They click a link, they get a page. Click, page. Form, Click, page. But not every problem is a nail for this simple hammer. In practice, I'd say there are a few gotchas to be aware of w/ page-centric approaches. One is the general issue of conceptual weight. This is probably worse for shlubs like me, but even then, there tend to be more things to be kept track of, more potential interactions , and more things to know about -- especially because I feel, in practice, Wicket doesn't let you know THAT much less about the HTML, Javascript, and CSS,(There are exceptions, for the prebuilt component, but those aren't core Wicket.) but requires you to understand how to apply that knowledge in the Wicket context. The second gotcha for people, especially who are a bit procedural minded, is the stacktrace problem. The more OO- you are, the more what you are seeing on screen (whether a complete webpage or a stacktrace) is the result of properly established object and relations earlier in the app workflow, the tougher it can be to know where the mistake occurred. Sometimes it's not a problem, and the 2 lines you see of your code are around where the error was, and other times Wicket is pretty helpful in telling you the kind of thing that went wrong. So in short... I get objects and have for a while. But I'm learning that there are further levels of getness I can aspire to. In an OO language one can wrap data and behavior up into objects and then assemble those objects and pass them to other objects. From my perspective that is the value that Wicket brings to web development. Now a developer has the power of OO instead of being stuck writing the same sort of procedural code that would be at home in Cobol. The bright side to all of this is that a Java developer that gets OO is worth 3 or 4 that don't. I review most of the interviews that come in to Vegas.com and I conduct most of the phone screen interviews. I don't consider anyone who doesn't get objects. That is our base line for entry. So put in the work. It's worth it. Oh, and does anyone want to move to sunny Las Vegas and work with a team of a dozen other developers who get it? We're still hiring -- especially folk with experience with Wicket. Cheers, Scott On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote: Well, that's a good point-- They aren't complex, per se, but they (and especially anonymous inner classes) seem to show up a lot more in the class of programming of which Applets and Wicket are both subsets than they do in most of the rest of Java land. So they're a little less familiar to me, and I'm not sure if they represent more complexity (given they're obviously fancier than using more generic data structures in that they may be doing arbitrarily complex things in their functions) or less (since they live in the same .java file as the page, and can be nicely tuned to handle the problem at hand). On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote: heh, if you think inner classes are complex you are def using the wrong framework -igor On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote: Ok, thanks... I refactored what i had with this in mind. It was a little more
Re: best practice for a header component with links defined by the page
Igor, I'm sorry I've sounded unappreciative to the work the team is doing. Yes, I'm a dumb curmudgeon who is having a lot of problems adjusting to a new approach to things, and who, despite an honest effort to embrace the wicket outlook, may have stumbled, and also dove right in to the code base we started here with not enough in-depth reading of Pro Wicket and fiddling around with more toy examples and then after that, started to get childishly frustrated when things didn't go the way I expected. On slashdot I'm more inclined to state my biases in an extreme way, in part to get some counterargument -- and there actually ended up being some good counterargument there, some wicket fans who expressed how much they dig the approach. My team has decided on wicket as the extensible, page centric approach to the fairly complex app we have to write, and so far I've done a poor job of thinking about Wicket deeply enough to know the best approaches to things. It's why I came here with a question like what would be the better way of doing this. Having had fragments pointed out to me (I knew more about panels, I think... at least to the extent of using them to wrap other components), and possibly thinking in terms of repeaters even though it's only going to be 2 or 3 things, I'll try to find some time and go back over some tutorials. On 8/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote: I just dont understand how you expect us to continue helping you if you go and talk trash about something we invest a lot of time in. Based on the slashdot comments you left I dont really understand why you are using wicket at all. -igor On 8/29/07, Kirk Israel [EMAIL PROTECTED] wrote: Igor, sorry if I've irritated you. I know some of my frustration comes from A. an ugly reluctance to embrace change and B. Wicket is doing great things but it's somewhat early days, and the documentation (tutorial books and recipe collections) is still scanty. Eelco, thanks, your summary was accurate. I thought about a repeater, it seemed like overkill, and I thought maybe there was a third way. (I still have to look into how the encompassing page would feed the links into the component, maybe not that difficult) So am I correct in thinking that, in general, most HTML pages in WIcket will have all possible subcomponents listed, and the visibility will control things that shouldn't be there... On 8/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote: or just write something in perl and call it a day. -igor On 8/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: So let me try to rephrase your problem: you have a header component that shows a variable number of components (links). Use a repeater (e.g. list view or repeating view) for the variable number of components, and you probably want to wrap the header component in a panel so that it is easy to move it around, place it on other pages, etc. Think a bit about whether those links should be internal or to bookmarkable pages, and that should do the trick, right? Eelco On 8/29/07, Kirk Israel [EMAIL PROTECTED] wrote: Hey there-- So I came up with a solution to this, but I suspect it's not very Wicket-y, so I'd like some suggestions on best practices: We want a header component that can go on different pages, with 1 2 or 3 links to other pages. (Well, I guess ideally any #, but with my approach it was easier to match it to the maximum shown in the spec). Visually, the end result would be Back to: _LINK1_, _LINK2_ or _LINK3_ As far as i can tell, the links and their labels should be created by the page containing the component. The trouble is, since the HTML and wicket:id for displaying each link is in the HTML for the component, the page has to know what ID to assign its link (and it doesn't seem like you can change the id of a component object after its created, which would have meant the page could just hand a list of un-ID'd labeled links in, and the component could have re-IDed them to match the HTML) So the component has a static callback getIdPrefixForLink() and getIdPrefixForLinkLabel(), and the page uses that, and then uses that string + 0, 1, or 2 for the links its making and handing to the constructor of the Header component. So if the Component only gets 1 Labeled Link, it then creates placeholder objects for the other 2, to make sure the hierarchy as outlined in the HTML is still ok, and then just hides them. And there's a tad more logic for the commas and the or. So, this all seems really hacky to me. What's a better way? In other words: Is having to make place holders for everything that ever MIGHT appear on a page or component, and then making them invisible when you don't need them, the Wicket way
Re: best practice for a header component with links defined by the page
Ok, thanks...
I refactored what i had with this in mind. It was a little more
complicated because I want to delegate responsibility for generating
the link and caption to the page (some of our links our kind of
complex to promote lazy initialization), so the page is still calling
into static functions to know what id to give the caption and label.
Plus I had to create an additional class to hold that link plus the
seperator( to do the comma and or in something like A, B or C)
The list is then
add(new ListView(linklist, listSepLinks)
{
private static final long serialVersionUID = 0L;
public void populateItem(final ListItem listItem)
{
CaptionedLinkAndSeperator linkAndSep =
(CaptionedLinkAndSeperator)listItem.getModelObject();
listItem.add(linkAndSep.getPageLink());
listItem.add(new Label(sep,
linkAndSep.getSeperator()));
}
});
and the HTML is then
span wicket:id=linklist
a href=# wicket:id=link class=linkspan
wicket:id=caption[LINK CAPTION]/span/aspan wicket:id =
sep[,]/span
/span
So, the complexity isn't too bad despite the inner class and it's less
kludgey than what i had earlier.
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice for a header component with links defined by the page
Igor, sorry if I've irritated you. I know some of my frustration comes from A. an ugly reluctance to embrace change and B. Wicket is doing great things but it's somewhat early days, and the documentation (tutorial books and recipe collections) is still scanty. Eelco, thanks, your summary was accurate. I thought about a repeater, it seemed like overkill, and I thought maybe there was a third way. (I still have to look into how the encompassing page would feed the links into the component, maybe not that difficult) So am I correct in thinking that, in general, most HTML pages in WIcket will have all possible subcomponents listed, and the visibility will control things that shouldn't be there... On 8/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote: or just write something in perl and call it a day. -igor On 8/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote: So let me try to rephrase your problem: you have a header component that shows a variable number of components (links). Use a repeater (e.g. list view or repeating view) for the variable number of components, and you probably want to wrap the header component in a panel so that it is easy to move it around, place it on other pages, etc. Think a bit about whether those links should be internal or to bookmarkable pages, and that should do the trick, right? Eelco On 8/29/07, Kirk Israel [EMAIL PROTECTED] wrote: Hey there-- So I came up with a solution to this, but I suspect it's not very Wicket-y, so I'd like some suggestions on best practices: We want a header component that can go on different pages, with 1 2 or 3 links to other pages. (Well, I guess ideally any #, but with my approach it was easier to match it to the maximum shown in the spec). Visually, the end result would be Back to: _LINK1_, _LINK2_ or _LINK3_ As far as i can tell, the links and their labels should be created by the page containing the component. The trouble is, since the HTML and wicket:id for displaying each link is in the HTML for the component, the page has to know what ID to assign its link (and it doesn't seem like you can change the id of a component object after its created, which would have meant the page could just hand a list of un-ID'd labeled links in, and the component could have re-IDed them to match the HTML) So the component has a static callback getIdPrefixForLink() and getIdPrefixForLinkLabel(), and the page uses that, and then uses that string + 0, 1, or 2 for the links its making and handing to the constructor of the Header component. So if the Component only gets 1 Labeled Link, it then creates placeholder objects for the other 2, to make sure the hierarchy as outlined in the HTML is still ok, and then just hides them. And there's a tad more logic for the commas and the or. So, this all seems really hacky to me. What's a better way? In other words: Is having to make place holders for everything that ever MIGHT appear on a page or component, and then making them invisible when you don't need them, the Wicket way, or is there something more direct? And/or is there a standard way of letting parent pages or component make subsubcomponents to be added to a subcomponent (e.g the Page making PageLinks to be added to the Header component -- incidentally I can't just pass in a reference to the class, because of what we had to do to make lazy loading links that don't fully instantiate the page they go to until that link is clicked.) - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sharing a context menu across components
So I haven't found what setup would provide a reference to the Behavior to the AjaxFallbackLink. Is the problem in how I'm relying on overloading the page's document.oncontextmenu to handle the right click event, and I should be using something else? As a workaround, is there any available Javascript function that other javascript can call to set the property of a page? Then the context menu could read the id from the tr the rowItem built, store that in the current page for the session, and then when the AjaxFallbacklink is triggered it could read it from there... is anything like that available, some public bit of API, like for an AjaxFallback link or something more direct, that javascript could easily call? On 8/14/07, Kirk Israel [EMAIL PROTECTED] wrote: I guess, then, the problem might be with the way I'm using the behavior(s) to activate some javascript to display the context menu at the appropriate place. (Code I took over, though I'm free to refactor it.) Sure each behavior has a unique path, but the AjaxLink in the context menu, the bit that actually does the work has no object reference (or otherwise) to the Behavior, so it doesn't help me determine what row was clicked. So either there is another way to set up the objects to produce the context menu, so that the Behavior is handed to whatever responds to the click, or I need to continue my current path of still having multiple behaviors, but modifying the javascript somehow to store the id in a hidden form or hack some URL that I haven't dug up yet. On 8/13/07, Igor Vaynberg [EMAIL PROTECTED] wrote: what i am suggesting is this: if you only want to have a single instance of behavior per table, yet have onclick react per row you need to have some javascript on the clientside that can tell what row is clicked by appending something meaningful to the behavior's callback url. you do not need this when you use an instance of behavior per row - because wicket already builds the unique name that can identify that row/behavior for you - which is the component path of the component that contains the behavior. -igor On 8/13/07, Kirk Israel [EMAIL PROTECTED] wrote: I guess I'm not understanding what you're suggesting. I've added a ContextMenuBehavior to the dataTableComponent row. Inside the ContextMenuComponent that is also on the page, there is an AjaxLink anonymous inner class. that overrides onClick(AjaxRequestTarget pRequestTarget) But the result of getPath() always has the same problem, even when I do ContextMenuComponent.this.getPath(). The Behavior isn't in the path, because it's not part of the nesting hierarchy. It stands outside and connects, and as you can see below the path says dataTableComponent:campaignContextMenuComponent - the fact that behaviors have been added to the dataTableComponent's rows doesn't matter to the path, at least in the straight forward way I've made the contextMenuComponent. (Just to make sure I wasn't missing something obvious, I tried adding the contextMenuComponent to the Behavior rather than to the dataTableComponent, but of course there is no .add(Component) for behaviors, so the concept didn't make sense.. you can add a behavior to a component but not vice versa) What am I not getting here? Is there some other kind of special menu item class I need to use that would capture the path of the behavior that invoked it?( Because right now it's just a component that happens to be showing up and relocated because of the behavior i added to the rowitem.) Is there some sort of way of jamming the behavior into the path, besides the fact that the behavior is added to the appropriate rowitem? On 8/13/07, Igor Vaynberg [EMAIL PROTECTED] wrote: see component.getpath() -igor On 8/13/07, Kirk Israel [EMAIL PROTECTED] wrote: Where can I retrieve that path? Each row is generating a unique behavior object instance, but in the onClick for one of the menu items, code like this.getRequest().getPath(); (which, through some documentation surfing and trial and error seemed the only thing close to what you were talking about) comes back with 1:campaignManagerViewContainer:dataTableComponent:campaignContextMenuComponent:contextmenuNewLink with no mention of the behavior that is connecting dataTableComponent and campaignContextMenuComponent Is there another object that would be carrying more meaningful request path info, or is my only hope to start hacking in the javascript? I really hate breaking the abstraction layer Wicket provides by putting so much in javascript, and the path to even do so isn't clear to me. On 8/13/07, Igor Vaynberg [EMAIL PROTECTED] wrote: the first one is internal to wicket - because the behavior is unique it gets
wicketstuff-dojo questions and answers
I'm getting the feeling this list doesn't have a ton of patience for questions it considers dumb. (or related to a library rather than core wicket) So with the idea that I might have asked a few dumb things, and to show that I'm trying to resolve things on my own, I'm going to give my answers to the questions I do have: Q. Can I attach the same wicketstuff-dojo DojoMenu to multiple components? A. No. Although some Wicket behaviors can be attached to multiple compontents, DojoContextualMenuBehavior requires each element get its own DojoMenu. Q. How do I modify the color and spacing of the context menu? A. You'd need to override the generate*JS functions in a subclass of DojoMenu and DojoMenuItem to point to your own CSS class (probably mostly cut and pasted from the .css dug out of the Wicketstuff-Dojo source.) Q. How do you get line separators between menu items? A. You'd have to make up a new DojoMenuItemSeperator class, and figure out how to compose the the underlying javascript to support that. Q. How would you dynamically change the icon for a menu item? A. You'd either have to create an entirely new menu, getting the element to drop its old behavior and connect it with the new version or possibly extend DojoMenuItem so that it could reset the icon, but this would require reaching more into the mysterious javascript. Q. a. Why isn't this stuff documented in more depth? b. And why don't people answer every stupid little question I have. A. a. Wicketstuff-Dojo is still a fairly young project with people who are currently more into coding it for more functionality than documenting. You're certainly welcome to contribute. b. These volunteers aren't interested in doing your work for you! And they're busy. And your questions are sometimes dumb. All that said, I'm considering going back to the approach of making my own context menu from more low level components (actually a lot of the work on that was already done by another guy at my company, but we hoped to leverage something as cool and easy to integrate as the Wicketstuff-Dojo menu; but we have pretty stringent look-and-feel demands, and while the Dojo stuff looks good, it isn't especially easy to reconfigure...) Thanks for any improvements to my answers! Kirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicketstuff-dojo questions and answers
On 8/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote: On 8/8/07, Kirk Israel [EMAIL PROTECTED] wrote: not the case. what you have to understand is that dojo stuff is a wicket-stuff project. created and maintained by developers that are not core developers. so it is really up to those developers to monitor this list and answer questions. Ok. But most side projects (including Wicketstuff/Wicketstuff-Dojo) haven't forked their own mailing lists or discussion groups, true? Nothing leapt out after searching through the wiki pages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DojoMenu, adding same to multiple components?
Looking at the DojoMenu and DojoContextualMenuBehavior javadoc and experimenting with it; is there any way to get the same DojoMenu to appear from multiple items? (Seems like not, the last one wins...but we'd prefer not to load up the page with more javascript for each item we'd like to do context menu operations on) If not, if you attach it to a AjaxFallbackDefaultDataTable, is there a way to do different things based on what row item it's connected to? And is there a better place to ask questions like this? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ResourceReference and Wicketstuff Dojo Documentation-related questions
I just discovered the jdocs for Wicket http://www.jdocs.com/tab/91/overview-summary.html Are there any other good, comprehensive references I should know about? And is there a better forum for than this list for Wicketstuff-Dojo related questions? Specifically, I'm wondering about how to attach specific behaviors to DojoMenuItem ; it might be following established paradigms I'm not familiar enough with yet. When I google on DojoMenuItem nothing documentation-y comes up. So I guess as much as anything, I'm looking to make sure I have the best possible reference resources to all this stuff, understanding that a lot of stuff seems to be very lightly documented... Also: with ResourceReference, as showin in the Wicketstuff-Dojo Contextual menu example, does the underlying image file live in the same directory as the .java and .html or somewhere else? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
