Re: Component Factory and code against interface
a bit more info: in wicket 1.3 (default with SLC) the change objects aren't
really used anymore
(they are not stored). They only cause an increment of the page version
number..
johan
On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
heh, there is nothing that automatically marks components as dirty()
because
wicket doesnt know what you do inside your components. wicket is
unmanaged.
If I do Component.setVersioned(true) and hook in my own
IPageVersionManager
won't Wicket effectively track dirty components for me? In a lot of user
interactions very few components will change so presumably using Wicket
component level versioning would be more effecient for us? It won't
track
everything but since setEnabled, setVisible etc are final I've not that
many
choices...
Wicket's change tracking is only done for explicit changes though. For
instance:
private class CurrentPageChange extends Change {
private final int currentPage;
CurrentPageChange(int currentPage) {
this.currentPage = currentPage;
}
public void undo() {
setCurrentPage(currentPage);
}
}
...
addStateChange(new CurrentPageChange(this.currentPage));
You can definitively use this for your own purposes. However, I would
think that the typical thing *you* want to react on are model changes.
You can use this mechanism for it as well, but it might be heavier
than you'd like.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
Thanks Johan and Eelco,
I'm going to consider the model as opaque as far as change tracking is
concerned. I just want an easy way to track dirty components so looks like
this is the way to go unless it is going away completely. Since so many
methods are final the only options I can think of are polling components for
change, our own build of Wicket, explicit marking or AOP. None of which
sound attractive.
btw Using wicket is so so nice compared to struts etc. Turns out I'm the
weakest link trying to remember how to program in OO ;) Many thanks to you
and the other developers.
Johan Compagner wrote:
a bit more info: in wicket 1.3 (default with SLC) the change objects
aren't
really used anymore
(they are not stored). They only cause an increment of the page version
number..
johan
On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
heh, there is nothing that automatically marks components as dirty()
because
wicket doesnt know what you do inside your components. wicket is
unmanaged.
If I do Component.setVersioned(true) and hook in my own
IPageVersionManager
won't Wicket effectively track dirty components for me? In a lot of
user
interactions very few components will change so presumably using Wicket
component level versioning would be more effecient for us? It won't
track
everything but since setEnabled, setVisible etc are final I've not that
many
choices...
Wicket's change tracking is only done for explicit changes though. For
instance:
private class CurrentPageChange extends Change {
private final int currentPage;
CurrentPageChange(int currentPage) {
this.currentPage = currentPage;
}
public void undo() {
setCurrentPage(currentPage);
}
}
...
addStateChange(new CurrentPageChange(this.currentPage));
You can definitively use this for your own purposes. However, I would
think that the typical thing *you* want to react on are model changes.
You can use this mechanism for it as well, but it might be heavier
than you'd like.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12473771
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
On 9/4/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Johan and Eelco, I'm going to consider the model as opaque as far as change tracking is concerned. I just want an easy way to track dirty components so looks like this is the way to go unless it is going away completely. Since so many methods are final the only options I can think of are polling components for change, our own build of Wicket, explicit marking or AOP. None of which sound attractive. If some finals are in the way, and you have a real good use case for us, we can always consider removing. We've done that in the past. As for your strategy to track dirty components... I'm really not sure now whether using Wicket's change mechanism is the best way to go. Like Johan said, what is done with it depends on the version manager in use, which depends on the session store in use. We might have to remove final from Component#addStateChange to facilitate listening to changes without having to jump through too many loop holes. I'm still wondering whether it is really the component changes you are after. If you are building something completely generic, maybe yes, and maybe this should be part of Wicket then. Otoh, I expect that typical applications are actually interested in reflecting data changes, which are typically not communicated through component changes. The problem is though, that for the sake of efficiency, we only pull data when we need it. I.e. when rendering the components. And as with Ajax you only want to do partial renders... Though one this. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
Thanks Eelco, It is mainly navigation logic and I think its state can quite happily live in the components... I have the habit of having a fixUpTheStateOfThisWidget method (real name changed to protect the guilty) that I'm starting to wonder if I can hook this into marking components as dirty. So maybe I can get away with explicit marking of components as dirty. So at least my application code does not see the gory details of Ajax, code handlers only once and changes get cascaded... Anyway, I'll see if I can manage without setEnabled, setVisible, add, addOrReplace etc not being final... Perhaps coming from GWT I imagined Wicket would magically handle all the state changes for me. All the AjaxTarget stuff seems very low level for writing user interfaces. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12483783 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
I have the habit of having a fixUpTheStateOfThisWidget method (real name changed to protect the guilty) that I'm starting to wonder if I can hook this into marking components as dirty. So maybe I can get away with explicit marking of components as dirty. Or e.g. work with bean properties and use property change listeners. Perhaps coming from GWT I imagined Wicket would magically handle all the state changes for me. All the AjaxTarget stuff seems very low level for writing user interfaces. Yeah. Thing is that everything in Wicket works automatically for normal processing. Since GWT is Ajax only, and they 'own' everything that happens in the browser, they can do that. The way Ajax with Wicket currently works is very flexible etc, but agreed requires more hand work. It's not a static framework though. We're always on the lookout for improving things, and this might be an area for that. You could open a JIRA issue (feature request) for it so that we make this discussion more persistent. And of course, please share any insights you might develop while working on this. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
igor.vaynberg wrote: On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote: heh, there is nothing that automatically marks components as dirty() because wicket doesnt know what you do inside your components. wicket is unmanaged. If I do Component.setVersioned(true) and hook in my own IPageVersionManager won't Wicket effectively track dirty components for me? In a lot of user interactions very few components will change so presumably using Wicket component level versioning would be more effecient for us? It won't track everything but since setEnabled, setVisible etc are final I've not that many choices... -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12461509 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
igor.vaynberg wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
heh, there is nothing that automatically marks components as dirty()
because
wicket doesnt know what you do inside your components. wicket is
unmanaged.
If I do Component.setVersioned(true) and hook in my own IPageVersionManager
won't Wicket effectively track dirty components for me? In a lot of user
interactions very few components will change so presumably using Wicket
component level versioning would be more effecient for us? It won't track
everything but since setEnabled, setVisible etc are final I've not that many
choices...
Wicket's change tracking is only done for explicit changes though. For instance:
private class CurrentPageChange extends Change {
private final int currentPage;
CurrentPageChange(int currentPage) {
this.currentPage = currentPage;
}
public void undo() {
setCurrentPage(currentPage);
}
}
...
addStateChange(new CurrentPageChange(this.currentPage));
You can definitively use this for your own purposes. However, I would
think that the typical thing *you* want to react on are model changes.
You can use this mechanism for it as well, but it might be heavier
than you'd like.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
think of a better way of doing it than the Swing/AWT style with our own simple objects being proxies to different Wicket components. e.g. AjaxButton or Button... What would you do if you were me? Before I try and make our prototype ship shape ;) Today your words seemed even more true as I'm tempted to digress from the Wicket style and use event handler style: someButton.add(new EventHandler... So as you say writing our own framework. igor.vaynberg wrote: the ui layer is generally not portable. if you start building your own abstraction to make it portable you will end up with a pretty big mess because you will be working against whatever framework you are using and eventually that abstraction will turn into a framework itself. -igor On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote: Many thanks Igor, that sounds like a very pragmatic approach. I was thinking about all sorts of horrible kludges like re-rendering the whole page and seeing how elements changed or hooking into the serialisation. Taken away another reason to do my over complicated solution ;) Am I worrying over nothing that developers might get carried away using vast number of components and fiddling with attributes that will make the application difficult to test and maybe one day port? Restricting the set of components can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12441886 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12446696 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12441886 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
igor, I've not been able to get rid of the requirement I've been given to support an Ajax capable client and old browser with tiny bit of JavaScript. Your words seem more true than ever but I can't think of a better way of doing it than the Swing/AWT style with our own simple objects being proxies to different Wicket components. e.g. AjaxButton or Button... What would you do if you were me? Before I try and make our prototype ship shape ;) Today your words seemed even more true as I'm tempted to digress from the Wicket style and use event handler style: someButton.add(new EventHandler... So as you say writing our own framework. igor.vaynberg wrote: the ui layer is generally not portable. if you start building your own abstraction to make it portable you will end up with a pretty big mess because you will be working against whatever framework you are using and eventually that abstraction will turn into a framework itself. -igor On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote: Many thanks Igor, that sounds like a very pragmatic approach. I was thinking about all sorts of horrible kludges like re-rendering the whole page and seeing how elements changed or hooking into the serialisation. Taken away another reason to do my over complicated solution ;) Am I worrying over nothing that developers might get carried away using vast number of components and fiddling with attributes that will make the application difficult to test and maybe one day port? Restricting the set of components can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
yeah, im def not saying that _everything_ will work like that, but it is _possible_ to do it. what we did is already cover the most common things like links and form submit buttons. so try to get that case working first instead of switching between button and ajaxbutton use ajaxfallbackbutton. what will happen is that your app will work with ajax in a browser, but as soon as you turn javascript off it will work with regular requests. all pretty much transparent. when you get that working the next step will be to crate a ajaxfallbackdropdown that will do ajax onchange notifications where possible, and fallback on regular when not. you can build a layer of these ajaxfallback components for your app. that is probably the way to go. it isnt 100% flexible, but you can work on that later. one step at a time. -igor On 8/31/07, Sam Hough [EMAIL PROTECTED] wrote: Igor, Thanks. I did have a look at that early on (so maybe I wasn't thinking Wicket enough to get it). It seemed to me that that didn't really help for things like forms etc that we want to work in Ajax style (partial update etc) and with full page refresh (only JavaScript being onchange for select element). Our test example for our prototype is a query builder where you can add/remove conditions and part of the form changes if you change what field you are searching. I can't see how to do this without switching between AjaxButton and Button depending on type of browser... Also changing if ListChoice uses the AjaxFormComponentUpdatingBehavior or onSelectionChanged... Wicket seems setup to allow power users to build very intricate Ajax app _OR_ plain HTML not really both at the same time. Sorry if I'm being thick. Think I'm bright enough for your original comment to worry me. Trying to grow out of the sort of geek who always has to rewrite everything ;) igor.vaynberg wrote: we already have support for unobtrusive ajax via AjaxFallbackLink and AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it will be just what you are looking for. -igor On 8/31/07, Sam Hough [EMAIL PROTECTED] wrote: igor, I've not been able to get rid of the requirement I've been given to support an Ajax capable client and old browser with tiny bit of JavaScript. Your words seem more true than ever but I can't think of a better way of doing it than the Swing/AWT style with our own simple objects being proxies to different Wicket components. e.g. AjaxButton or Button... What would you do if you were me? Before I try and make our prototype ship shape ;) Today your words seemed even more true as I'm tempted to digress from the Wicket style and use event handler style: someButton.add(new EventHandler... So as you say writing our own framework. igor.vaynberg wrote: the ui layer is generally not portable. if you start building your own abstraction to make it portable you will end up with a pretty big mess because you will be working against whatever framework you are using and eventually that abstraction will turn into a framework itself. -igor On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote: Many thanks Igor, that sounds like a very pragmatic approach. I was thinking about all sorts of horrible kludges like re-rendering the whole page and seeing how elements changed or hooking into the serialisation. Taken away another reason to do my over complicated solution ;) Am I worrying over nothing that developers might get carried away using vast number of components and fiddling with attributes that will make the application difficult to test and maybe one day port? Restricting the set of components can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: Component Factory and code against interface
Igor, Thanks. I did have a look at that early on (so maybe I wasn't thinking Wicket enough to get it). It seemed to me that that didn't really help for things like forms etc that we want to work in Ajax style (partial update etc) and with full page refresh (only JavaScript being onchange for select element). Our test example for our prototype is a query builder where you can add/remove conditions and part of the form changes if you change what field you are searching. I can't see how to do this without switching between AjaxButton and Button depending on type of browser... Also changing if ListChoice uses the AjaxFormComponentUpdatingBehavior or onSelectionChanged... Wicket seems setup to allow power users to build very intricate Ajax app _OR_ plain HTML not really both at the same time. Sorry if I'm being thick. Think I'm bright enough for your original comment to worry me. Trying to grow out of the sort of geek who always has to rewrite everything ;) igor.vaynberg wrote: we already have support for unobtrusive ajax via AjaxFallbackLink and AjaxFallbackButton. read the javadoc for AjaxFallbackLink, i think it will be just what you are looking for. -igor On 8/31/07, Sam Hough [EMAIL PROTECTED] wrote: igor, I've not been able to get rid of the requirement I've been given to support an Ajax capable client and old browser with tiny bit of JavaScript. Your words seem more true than ever but I can't think of a better way of doing it than the Swing/AWT style with our own simple objects being proxies to different Wicket components. e.g. AjaxButton or Button... What would you do if you were me? Before I try and make our prototype ship shape ;) Today your words seemed even more true as I'm tempted to digress from the Wicket style and use event handler style: someButton.add(new EventHandler... So as you say writing our own framework. igor.vaynberg wrote: the ui layer is generally not portable. if you start building your own abstraction to make it portable you will end up with a pretty big mess because you will be working against whatever framework you are using and eventually that abstraction will turn into a framework itself. -igor On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote: Many thanks Igor, that sounds like a very pragmatic approach. I was thinking about all sorts of horrible kludges like re-rendering the whole page and seeing how elements changed or hooking into the serialisation. Taken away another reason to do my over complicated solution ;) Am I worrying over nothing that developers might get carried away using vast number of components and fiddling with attributes that will make the application difficult to test and maybe one day port? Restricting the set of components can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12426453 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12429106 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
specific handlers where possible. Have you seen anybody automatically marking components as dirty so they can be sent back via Ajax (Echo like)? I think that would handle 90% of our Ajax like stuff. Cheers Sam -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12290179 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12296693 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12298767 Sent from the Wicket - User mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308607 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
Thanks Johan,
Glad it wasn't a totally silly idea. Any top tips or problems you can share?
Nice that Igor's approach by its very nature avoids sending the same
component more than once. Trees are great ;)
Johan Compagner wrote:
this is how we also do it. Have a changes recorder per component, that
records changes and when the component renders it sets the dirty flag
to false
On 8/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Two motivations for dirty components being sent automatically are:
1) What gets updated may be through quite convoluted logic. e.g. user
changes ownership of a record so delete button gets disabled. I don't
really
want to code that the delete button needs resending...
how is any UI framework supposed to know that this happened? the
component
knows how to render itself based on this record you provide via a model,
but
it cannot tell it changed. this seems like such a corner case.
here is what i would suggest
interface IDirtyStateAware { boolean isDirty(); } let your components
that
know how to check if they are dirty or not implement this. i dont think
these should be as granular as a button, but probably bigger components -
like a panel that contains the button.
then:
AjaxFallbackLink link=new AjaxFallbackLink(link) {
abstract onClick(); // this is where processing happens
onClick(AjaxRequestTarget target) {
onClick();
getPage().visit(new component.visitor() {
visitcomponent(component c) {
if (c instanceof idirtystateaware) {
if (((idirtystateaware)c).isDirty()) {
target.addcomponent(c);
}
return CONTINUE_BUT_DONOT_GO_DEEPER;
}
return CONTINUE;
}
}
}
-igor
2) I'm probably missing some Wicket magic but as we have the HTML edition
and Ajax edition Id like the onsubmit etc handlers not to see any Ajax
stuff.
At the moment I'm pondering having something like:
AppSpecificPanel extends OurPanelBase. We then have the normal Wicket
implementation with an adapter that does the work for OurPanelBase. The
idea
being that:
* New developers are given a simple set of Components approved by our
tech
lead and tested.
* New developers can't fiddle with full power of Wicket.
* Bulk of application code is not tied to Wicket.
* At runtime can have different implementations of a particular
component
based on the client.
Obviously the huge downside is added complexity and trying to avoid
inventing our own API. I intend to have our own base class for Panel,
Button... etc so that we can be consistent about a variety of things.
Sorry I've rambled a bit.
igor.vaynberg wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Say my onSubmit handler changes three components, as I understand
it, I
have
to hand code feeding those three components to the
AjaxRequestTarget.
This
seems cumbersome and slightly error prone. I think for our
application,
if
the components kept track of changes, I could automate which
components
are
sent back. Guess what I'm asking is if anything that already exists
in
Wicket keeps track of component changes? Can't imagine it would be
easy
otherwise without really heavy duty AOP etc...
heh, there is nothing that automatically marks components as dirty()
because
wicket doesnt know what you do inside your components. wicket is
unmanaged.
but i dont really understand the issue. you have
onclick(ajaxrequesttarget
t) { dosomething(); t.addcomponent() }
so in your case you mean inside dosomething() you do something to x
components, but you dont know which x components they are?
-igor
Thanks again Igor.
igor.vaynberg wrote:
not really sure what you mean when you say marking components as
dirty...
have you seen ajaxfallback* components? those will use ajax when
its
there,
and fallback on regular requests when its not. so you dont even
need
a
factory necessarily.
-igor
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Thanks Igor,
Because we have to support Ajax and non-Ajax version I was
wondering
about
hiding details of making components Ajax friendly in the factory.
so
setOutputMarkupId(true) etc and hiding Ajax specific handlers
where
possible. Have you seen anybody automatically marking components
as
dirty
so
they can be sent back via Ajax (Echo like)? I think that would
handle
90%
of
our Ajax like stuff.
Cheers
Sam
--
View this message in context:
http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12290179
Sent from the Wicket - User mailing list archive at Nabble.com
Re: Component Factory and code against interface
the ui layer is generally not portable. if you start building your own abstraction to make it portable you will end up with a pretty big mess because you will be working against whatever framework you are using and eventually that abstraction will turn into a framework itself. -igor On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote: Many thanks Igor, that sounds like a very pragmatic approach. I was thinking about all sorts of horrible kludges like re-rendering the whole page and seeing how elements changed or hooking into the serialisation. Taken away another reason to do my over complicated solution ;) Am I worrying over nothing that developers might get carried away using vast number of components and fiddling with attributes that will make the application difficult to test and maybe one day port? Restricting the set of components can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
On 8/24/07, Johan Compagner [EMAIL PROTECTED] wrote:
We can do that because all our components implement specific interfaces
which changes
the state of the component. For example
interface ILabelMethods
{
setBackground(Color color)
setForeground(Color color)
// and so on
}
and all those implementations do record the change
On top of that, it might help to override the updateModel
implementations of form components to determine whether you have
changes?
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
Igor, We are not really trying to make it portable or our own abstraction. The aim would be a subset of the non-ajax Wicket API. In my comfortable ignorance it is a nice way to keep track of dirty components, hide details of ajax/non-ajax and let our tech lead keep firm control over which bits of wicket we use. I'm totally with you that this could turn into a real pain. Container systems like EJB2, Swing etc suggest it can go horribly wrong. igor.vaynberg wrote: the ui layer is generally not portable. if you start building your own abstraction to make it portable you will end up with a pretty big mess because you will be working against whatever framework you are using and eventually that abstraction will turn into a framework itself. -igor On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote: Many thanks Igor, that sounds like a very pragmatic approach. I was thinking about all sorts of horrible kludges like re-rendering the whole page and seeing how elements changed or hooking into the serialisation. Taken away another reason to do my over complicated solution ;) Am I worrying over nothing that developers might get carried away using vast number of components and fiddling with attributes that will make the application difficult to test and maybe one day port? Restricting the set of components can presumably end up with a more consistent UI... Anyway, thanks for all your time and sage advice. -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12308606 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12317759 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
not really sure what you mean when you say marking components as dirty... have you seen ajaxfallback* components? those will use ajax when its there, and fallback on regular requests when its not. so you dont even need a factory necessarily. -igor On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Igor, Because we have to support Ajax and non-Ajax version I was wondering about hiding details of making components Ajax friendly in the factory. so setOutputMarkupId(true) etc and hiding Ajax specific handlers where possible. Have you seen anybody automatically marking components as dirty so they can be sent back via Ajax (Echo like)? I think that would handle 90% of our Ajax like stuff. Cheers Sam -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12290179 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
Say my onSubmit handler changes three components, as I understand it, I have to hand code feeding those three components to the AjaxRequestTarget. This seems cumbersome and slightly error prone. I think for our application, if the components kept track of changes, I could automate which components are sent back. Guess what I'm asking is if anything that already exists in Wicket keeps track of component changes? Can't imagine it would be easy otherwise without really heavy duty AOP etc... Thanks again Igor. igor.vaynberg wrote: not really sure what you mean when you say marking components as dirty... have you seen ajaxfallback* components? those will use ajax when its there, and fallback on regular requests when its not. so you dont even need a factory necessarily. -igor On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Igor, Because we have to support Ajax and non-Ajax version I was wondering about hiding details of making components Ajax friendly in the factory. so setOutputMarkupId(true) etc and hiding Ajax specific handlers where possible. Have you seen anybody automatically marking components as dirty so they can be sent back via Ajax (Echo like)? I think that would handle 90% of our Ajax like stuff. Cheers Sam -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12290179 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12296693 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Say my onSubmit handler changes three components, as I understand it, I
have
to hand code feeding those three components to the AjaxRequestTarget. This
seems cumbersome and slightly error prone. I think for our application, if
the components kept track of changes, I could automate which components
are
sent back. Guess what I'm asking is if anything that already exists in
Wicket keeps track of component changes? Can't imagine it would be easy
otherwise without really heavy duty AOP etc...
heh, there is nothing that automatically marks components as dirty() because
wicket doesnt know what you do inside your components. wicket is unmanaged.
but i dont really understand the issue. you have onclick(ajaxrequesttarget
t) { dosomething(); t.addcomponent() }
so in your case you mean inside dosomething() you do something to x
components, but you dont know which x components they are?
-igor
Thanks again Igor.
igor.vaynberg wrote:
not really sure what you mean when you say marking components as
dirty...
have you seen ajaxfallback* components? those will use ajax when its
there,
and fallback on regular requests when its not. so you dont even need a
factory necessarily.
-igor
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Thanks Igor,
Because we have to support Ajax and non-Ajax version I was wondering
about
hiding details of making components Ajax friendly in the factory. so
setOutputMarkupId(true) etc and hiding Ajax specific handlers where
possible. Have you seen anybody automatically marking components as
dirty
so
they can be sent back via Ajax (Echo like)? I think that would handle
90%
of
our Ajax like stuff.
Cheers
Sam
--
View this message in context:
http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12290179
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12296693
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Component Factory and code against interface
Would it make sense in Wicket to have a factory, for at least common components like Button etc, that use interfaces rather than concrete classes in their signature? We have a requirement to have two target browsers. Full bells and whistles Ajax version and some JavaScript (IE5 and IE5.5) so I thought the factory pattern might allow me to return different components based on the client browser. Also, my tech lead can control what parts of a component a developer should play with. Maybe it is just coming from GWT or that pattern text books use Widgets as their example for Factory pattern but it seems like a reasonable thing to do? Anbody else tried this? Worked out well? Top tips? -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12272781 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
i dont see why it wouldnt work for you. i know some people who use osgi with wicket did this a while ago and no problems. -igor On 8/22/07, Sam Hough [EMAIL PROTECTED] wrote: Would it make sense in Wicket to have a factory, for at least common components like Button etc, that use interfaces rather than concrete classes in their signature? We have a requirement to have two target browsers. Full bells and whistles Ajax version and some JavaScript (IE5 and IE5.5) so I thought the factory pattern might allow me to return different components based on the client browser. Also, my tech lead can control what parts of a component a developer should play with. Maybe it is just coming from GWT or that pattern text books use Widgets as their example for Factory pattern but it seems like a reasonable thing to do? Anbody else tried this? Worked out well? Top tips? -- View this message in context: http://www.nabble.com/Component-Factory-and-code-against-interface-tf4311047.html#a12272781 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
