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 '' (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 HashMap.
> 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?
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]
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?
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]
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
HashMap 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]
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]
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]
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!
information on getting browser info
We've decided only to not support IE 6 or below. (Support only for IE7
and Firefox 2 - I'm not crazy about such narrow browser support, but
it is what it is.)
I have this code:
WebClientInfo w =
(WebClientInfo)getWebRequestCycle().getClientInfo();
ClientProperties cp = w.getProperties();
System.out.println("getNavigatorAppName'"+cp.getNavigatorAppName()+"'");
System.out.println("getNavigatorAppCodeName'"+cp.getNavigatorAppCodeName()+"'");
System.out.println("getNavigatorAppVersion'"+cp.getNavigatorAppVersion()+"'");
System.out.println("getBrowserVersionMajor'"+cp.getBrowserVersionMajor()+"'");
System.out.println("getBrowserVersionMinor'"+cp.getBrowserVersionMinor()+"'");
For Firefox, everything is nulls and -1s. For IE,
getBrowserVersionMajor is set, and, in a pich, I could probably base a
decent 90/10 solution on that.
But I suspect I'm doing something wrong, the cast makes me a little nervous.
I did Google up WebClientInfo and ClientProperties and all that but
couldn't use that to figure out how to make this better, or if there
was some kind of initialization step I missed.
Thanks!
-
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]
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]
suggesting alternative to IndicatingAjaxFallbackLink->class for just changing pointer/cursor
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]
Re: ModalWindow: open on page construction
Not during, after the page has finished loading. The useful aspect is this: most cool Ajax-y things people will have made rely on having that AjaxRequestTarget handy (most often in the onClick of a AjaxFallbackLink . There is a small, but real, number of circumstances where you want to do one of those things as soon as the page is done loading, rather than waiting for a user click. (And it would be cleaner to not have to manually call the javascript onClick, but keep it in the Java) My example, again, is a ModalWindow. Ideally I would have liked an upload button on our "view mode" page take the user to the edit mode page, and then have the edit mode fire off its upload ModalWindow. (the Edit Page already had its own Upload button). Instead, after trying a few things out, I was compelled to give the View Mode page its own Upload dialog, though I exposed what the Edit page was doing to make the window, so there wasn't TOO too much duplication. Then, on the ModalWindows onclose, it called the Edit Page's routine for what to do when the ModalWindow closed, and then jumped to the Edit Page. This made I had to create an instance of the Edit Page earlier than I wanted to... But if I had something like onPageDoneLoading(AjaxRequestTarget pArt) function, I could have used that in Edit Page to check a boolean, and then open up its own Modal Window. Thanks for at least thinking about my issue :-) -Kirk On Nov 17, 2007 1:47 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > No, there is no such thing as having ajax request target during page > load. What would it do, anyway? > > What we could do is making ModalWindow.getWindowOpenJavascript public, > so that you could use the resuling javascript in > IHeaderResponse.renderOnDomReadyJavascript(). > > -Matej > > > On Nov 16, 2007 7:50 PM, Kirk Israel <[EMAIL PROTECTED]> wrote: > > So my back up plans didn't work out as well as I had hoped. > > > > Is there any answer to this? > > > > Obviously, it would be lovely if there was some equivalent of the > > javascript body onLoad command (and maybe tied in with that) that > > could give the user an AjaxRequestTarget to play with... Is there > > anything like that around? > > > > > > > > On Nov 16, 2007 11:49 AM, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > (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] > > > > > > - > 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: ModalWindow: open on page construction
So my back up plans didn't work out as well as I had hoped. Is there any answer to this? Obviously, it would be lovely if there was some equivalent of the javascript body onLoad command (and maybe tied in with that) that could give the user an AjaxRequestTarget to play with... Is there anything like that around? On Nov 16, 2007 11:49 AM, Kirk Israel <[EMAIL PROTECTED]> wrote: > (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: 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]
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: updating components on Page from ModalWindow's internal Page's components
Ah, I was trying various permutations in google of wicket, ajax,
image, refresh, etc.
the resulting code was something like
mImage = new Image("imgTag", mResource){
private static final long serialVersionUID = 1L;
@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
tag.put("src", tag.getString("src") + "&imageid=" + mIDforURL);
}
};
where mIDforURL was actually a timestamp generated by the containing
compontent..
Thanks!
On 10/29/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> search the list for "updating images using ajax". It should give about
> 5-10 threads easily.
>
> And this finds:
> http://issues.apache.org/jira/browse/WICKET-939
>
> Martijn
>
> On 10/30/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
> > 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...
> > > > K
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'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
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]
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]
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]
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
Hey there
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
Hey there
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
> > 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:
> 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
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 "get"ness 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 th
Re: best practice for a header component with links defined by the page
Well of course they are "fancier" than, say, structs in C, simply
because they exist for a reason and can do things generic data
structures cannot. I'm familiar with them, have no trouble reading or
writing the syntax of them or understanding what they do, it's a
matter of using them enough that they leap more quickly to mind when
they're the appropriate tool for the job at hand. (As I did in the
case here, when I realized it made sense to have a wrapper that
contained the link as well as the "seperator" string to be stuck on
after during its display in an iteration.)
My experience with Java has been Model Two +, Struts, various APIs
(home grown and 3rd party) and (a mercifully brief time wrestling
with) EJBs. None of these made heavy use of anonymous inner classes.
Some of those were a bit procedural, but it still seems like, in
practice, it's mostly been Applets and other UI-ish things that that
made extremely frequent use of them.
Probably the most difficult grinding of gears, then, for someone who
gets the syntax and knows the basic concept in theory more than
practice, is the idea that it's reasonable to make small, single uses
class definitions (as opposed to setting properties on instances of
classes) for the task at hand and not worry that they can't or won't
be used elsewhere, just in the local file. On a surface level at
least, this goes against the grain of objects as reusable components
that should be first class objects (though obviously the trick can be
to make the appropriate first class objects that can then be
customized locally)
On 8/31/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> they are not "fancier" then generic data structures. they exist for a reason
> and can do things other generic data structures cannot. i suggest you read
> up on them, they are a pretty standard part of oop and are used throughout
> java - unless of course you have been living in a struts-like land where oop
> is replaced with procedural programming and you only use a small subset of
> java.
>
> -igor
>
>
> 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
> > > > 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
> > > >
> > > >
> > > > > > > wicket:id="caption">[LI
Re: best practice for a header component with links defined by the page
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
> > 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
> >
> >
> > > wicket:id="caption">[LINK CAPTION] > "sep">[,]
> >
> >
> > 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]
> >
> >
>
-
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
Also, not ignoring the fact I needed to have dug in more to the documentation that is there, why doesn't http://wicketstuff.org/wicket13/compref/ mention ListView ? Is there another reference (besides Javadoc) that would discuss more about it? - 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
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
[LINK CAPTION][,]
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, 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,
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]
best practice for a header component with links defined by the page
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]
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 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
Re: sharing a context menu across components
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 > > > an internal unique path in wicket, so you dont need to worry about it. > > so > > > basically your onclick handler for the menuitem has a 1-1 link to the > > > onclick handler of the behavior. > > > > > > if you want one behavior then you have many menuitems onclicks linking > > to a > > > single behavior onclick. so you need to map somehow - and that is > > through > > > javascript on clientside. > > > > > > -igor > > > > > > > > > On 8/13/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > > > > > I kind of see what you're getting at, but could you give an example of > > > > the syntax for the first one? I already have a unique behavior > > > > instance for each row... do I need to add another one? Or is there > > > > some way in the onClick code to read what the path of the behavior is? > > > > (Actually I might not be thinking of the right use of "path") > > > > I guess I'm trying to avoid hacking javascript strings if I can, since > > > > the link syntax is pretty arcane... > > > > > > > > On 8/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > the event is triggered on clientside, so you need to pass back what > > item > > > > was > > > > > clicked there. > > > > > > > > > > you can either do it by adding a unique behavior - which then has a > > > > unique > > > > > path - which is that "id" you are passing back. or you need to > > append > > > > some > > > > > unique id on client side using javascript so it can tell which row > > was > > > > > clicked. > > > > > > > > > > -igor > > > > > > > > > > > > > > > On 8/13/0
Re: sharing a context menu across components
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 > an internal unique path in wicket, so you dont need to worry about it. so > basically your onclick handler for the menuitem has a 1-1 link to the > onclick handler of the behavior. > > if you want one behavior then you have many menuitems onclicks linking to a > single behavior onclick. so you need to map somehow - and that is through > javascript on clientside. > > -igor > > > On 8/13/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > I kind of see what you're getting at, but could you give an example of > > the syntax for the first one? I already have a unique behavior > > instance for each row... do I need to add another one? Or is there > > some way in the onClick code to read what the path of the behavior is? > > (Actually I might not be thinking of the right use of "path") > > I guess I'm trying to avoid hacking javascript strings if I can, since > > the link syntax is pretty arcane... > > > > On 8/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > the event is triggered on clientside, so you need to pass back what item > > was > > > clicked there. > > > > > > you can either do it by adding a unique behavior - which then has a > > unique > > > path - which is that "id" you are passing back. or you need to append > > some > > > unique id on client side using javascript so it can tell which row was > > > clicked. > > > > > > -igor > > > > > > > > > On 8/13/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > > > > > I have a Context Menu Object and Behavior... right now I construct one > > > > Context Menu for the whole Data Table (extends > > > > AjaxFallbackDefaultDataTable) component that links to it... then on > > > > newRowItem() I add a unique ContextMenuBehavior (extends > > > > AbstractBehavior) to that item before returning. > > > > > > > > My ContextMenuComponent currently constructs AjaxFallbackLink > > > > derivatives to connect to the functions that will actually do the > > > > work. > > > > > > > > My question is, what's the best way of getting information on which > > > > Table item was actually clicked to the context menu? Obviously I'd > > > > rather not give each table item its own context menu... is there > > > > anything in AbstractBehavior that would get triggered when the user > > > > right clicks, and thus let me set a global-ish variable in the parent > > > > component that the contextmenu could then read? Or have we gone about > > > > that wrong, and it needs to be some other kind of behavior to activate > > > > server-side code when the behavior gets activated? > > > > > > > > I might be still having trouble setting my mind to the appropriate > > > > Wicket way of thinking about this kind of issue. > > > > > > > > Thanks... > > > > > > > > - > > > > 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
I kind of see what you're getting at, but could you give an example of the syntax for the first one? I already have a unique behavior instance for each row... do I need to add another one? Or is there some way in the onClick code to read what the path of the behavior is? (Actually I might not be thinking of the right use of "path") I guess I'm trying to avoid hacking javascript strings if I can, since the link syntax is pretty arcane... On 8/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > the event is triggered on clientside, so you need to pass back what item was > clicked there. > > you can either do it by adding a unique behavior - which then has a unique > path - which is that "id" you are passing back. or you need to append some > unique id on client side using javascript so it can tell which row was > clicked. > > -igor > > > On 8/13/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > I have a Context Menu Object and Behavior... right now I construct one > > Context Menu for the whole Data Table (extends > > AjaxFallbackDefaultDataTable) component that links to it... then on > > newRowItem() I add a unique ContextMenuBehavior (extends > > AbstractBehavior) to that item before returning. > > > > My ContextMenuComponent currently constructs AjaxFallbackLink > > derivatives to connect to the functions that will actually do the > > work. > > > > My question is, what's the best way of getting information on which > > Table item was actually clicked to the context menu? Obviously I'd > > rather not give each table item its own context menu... is there > > anything in AbstractBehavior that would get triggered when the user > > right clicks, and thus let me set a global-ish variable in the parent > > component that the contextmenu could then read? Or have we gone about > > that wrong, and it needs to be some other kind of behavior to activate > > server-side code when the behavior gets activated? > > > > I might be still having trouble setting my mind to the appropriate > > Wicket way of thinking about this kind of issue. > > > > Thanks... > > > > - > > 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]
sharing a context menu across components
I have a Context Menu Object and Behavior... right now I construct one Context Menu for the whole Data Table (extends AjaxFallbackDefaultDataTable) component that links to it... then on newRowItem() I add a unique ContextMenuBehavior (extends AbstractBehavior) to that item before returning. My ContextMenuComponent currently constructs AjaxFallbackLink derivatives to connect to the functions that will actually do the work. My question is, what's the best way of getting information on which Table item was actually clicked to the context menu? Obviously I'd rather not give each table item its own context menu... is there anything in AbstractBehavior that would get triggered when the user right clicks, and thus let me set a global-ish variable in the parent component that the contextmenu could then read? Or have we gone about that wrong, and it needs to be some other kind of behavior to activate server-side code when the behavior gets activated? I might be still having trouble setting my mind to the appropriate Wicket way of thinking about this kind of issue. Thanks... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicketstuff-dojo questions and answers
Good, because my group was beyond the point where "Setting up a Wicket project" was useful... and if we don't know "What is Wicket?" by now there's no hope for us :-) Strongly mixed feelings about the delay... I can see the appeal of having it as up to date as possible, but I'm hankering for documentation now, and my group is definitely in rush rush mode. On 8/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > It's too bad Wicket in Action has been so delayed. The environment is > > rich enough to deserve an alternate viewpoint! > > http://manning.com/dashorst/ available in MEAP now, this week we'll > hopefully put out two more chapters! :) > > It's actually good it is delayed imho. Not for me personally, but the > end-result will be a lot better than what we had a year ago (and of > course a lot more recent too). > > 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: wicketstuff-dojo questions and answers
Heh, sorry, I didn't mean for the "true?" to sound as whiny as it did -- just my ongoing fear, or hope, that there's some treasure trove of documentation and developers just WAITING to answer my every question, and I just haven't found it yet. It's too bad Wicket in Action has been so delayed. The environment is rich enough to deserve an alternate viewpoint! On 8/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > no they havent. i am not saying that this isnt the place to ask questions, i > am saying dont expect to receive the same quality of service as you receive > when asking questions about the core projects. also not that not everyone on > this list uses that wicket-stuff project, so probably most people know > nothing about it and cant help you. > > -igor > > > On 8/8/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > - 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]
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]
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]
