On 20 sep. 2011, at 19:12, Juliano Viana wrote:
> Hi,
>
> I have been following this discussion and I think its not fair to call
> Wicket Ajax support broken.
> I started using Wicket back in 2007, and the environment then was:
>
> - Support for IE 6 was a must.
> - JavaScript on the browser w
On Wed, Sep 21, 2011 at 2:43 AM, Ben Tilford wrote:
> With the js framework suggestions I havn't seen anyone mention a module
> system like require.js this would be something I'd wan't to see used. If
> something like jQuery gets included without a module system it would only be
> a matter of time
Yep, this is really important.
A bit of a rhetorical question: Why not design wicket.next with modularity as a
first-class requirement?
On Sep 20, 2011, at 7:43 PM, Ben Tilford wrote:
> With the js framework suggestions I havn't seen anyone mention a module
> system like require.js this woul
With the js framework suggestions I havn't seen anyone mention a module
system like require.js this would be something I'd wan't to see used. If
something like jQuery gets included without a module system it would only be
a matter of time until jQuery.next was released and someone wants to use it.
Well said, Juliano! Thanks for your contribution.
In my experience the awkward parts of interacting with JS/JQuery objects
from Wicket are
1. Converting model objects to/from JS strings
2. Invoking JS initialization functions (with data arguments) at the right
time, i.e. when a certain Wicket comp
Hi,
I have been following this discussion and I think its not fair to call
Wicket Ajax support broken.
I started using Wicket back in 2007, and the environment then was:
- Support for IE 6 was a must.
- JavaScript on the browser was still slow and unreliable
- The applications where designed t
If you are playing with Scala, and don't want to use the
instantiationListener because not all of your components are to be
ajaxified, you can then do:
object field1 extends TextField("field1") with AjaxReady
object field2 extends TextField("field2") with AjaxReady
object field3 extends TextField(
On Tue, Sep 20, 2011 at 12:53 AM, Korbinian Bachl - privat
wrote:
> tetsu, ever tried to:
>
> - get an AjaxRequestTarget in a component that was not designed by ajax in
> mind?
AjaxRequestTarget.get()
>
> - tried to ajaxify a table-row in a dataTable component?
new datatable() { new item() { re
On Tuesday, September 20, 2011 2:28 PM, "Korbinian Bachl - privat"
wrote:
>
> Am 20.09.11 13:11, schrieb Pointbreak:
> > I'm completely agreeing with Martin on this one. The things you are
> > suggesting imho have the following consequences:
> > - Wicket implementation becomes way more complicate
Am 20.09.11 13:11, schrieb Pointbreak:
I'm completely agreeing with Martin on this one. The things you are
suggesting imho have the following consequences:
- Wicket implementation becomes way more complicated, because Wicket has
to translate between component hierarchy and browser DOM-tree, whic
>
> tetsu, ever tried to:
>
It's tetsu*o*.
> - get an AjaxRequestTarget in a component that was not designed by ajax in
> mind?
>
Yes, and it works pretty well. I can't really remember a single case that I
couldn't do what I wanted to do. Sometimes I had to do it in a different way
than I tried
I'm completely agreeing with Martin on this one. The things you are
suggesting imho have the following consequences:
- Wicket implementation becomes way more complicated, because Wicket has
to translate between component hierarchy and browser DOM-tree, which is
non-trivial, and requires a lot of ex
Am 20.09.11 12:30, schrieb Martin Grigorov:
On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
wrote:
...
Wrong approach IMHO. The question is: Do we need outprinted Id's to find an
element in DOM?
Answer is: No, we don't as long as we know the path (!). Funnywise this path
is the s
On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
wrote:
> Heya,
>
> Am 20.09.11 11:37, schrieb Martin Grigorov:
> ...
>>>
>>>
>>> Ok, well, wicket consists of components. So basically it is making a page
>>> full of a tree with components. Wicket now could scan the component if it
>>> has
Heya,
Am 20.09.11 11:37, schrieb Martin Grigorov:
...
Ok, well, wicket consists of components. So basically it is making a page
full of a tree with components. Wicket now could scan the component if it
has any Ajax on it - then auto add what it needs like the setOuput... - so
we got rid of thi
Hi,
On Tue, Sep 20, 2011 at 12:08 PM, Korbinian Bachl - privat
wrote:
> Hi Martin,
>
> Am 20.09.11 09:59, schrieb Martin Grigorov:
> ...
>>>
>>> Well, I think there is consent that we can say current wicket ajax is
>>> quite
>>> broken and a big pain in everyday usage.
>>
>> Really? Is that broke
Hi Martin,
Am 20.09.11 09:59, schrieb Martin Grigorov:
...
Well, I think there is consent that we can say current wicket ajax is quite
broken and a big pain in everyday usage.
Really? Is that broken ?
Neither mailing lists questions nor tickets prove that statement.
The current ajax means loa
Hi Korbinian,
On Tue, Sep 20, 2011 at 10:48 AM, Korbinian Bachl - privat
wrote:
> Well, I think there is consent that we can say current wicket ajax is quite
> broken and a big pain in everyday usage.
Really? Is that broken ?
Neither mailing lists questions nor tickets prove that statement.
>
> T
tetsu, ever tried to:
- get an AjaxRequestTarget in a component that was not designed by ajax
in mind?
- tried to ajaxify a table-row in a dataTable component?
- tried ajax with repeaters?
- tried to interact with a modal window from inside in case you have a
pure non-ajax page within it?
Well, I think there is consent that we can say current wicket ajax is
quite broken and a big pain in everyday usage.
The current ajax means loads of code in java for even trivial things.
Triple-checking that a component knows its ajax and so on. So even *if*
it will break api in future, I don'
+1 as well, a compliment of [1]. There are a number of standardized client
architectures (like backbone) with significant followings, being able to
"Wicketize" a live mockup written in a single would be powerful. Creating a
standardized server environment to work with many of these platforms w
+1 for what Juliano said...something in the lines of what backbone.js but for
Wicket...History API support (pushState, replaceState, onPopState) would be
"wicket-ed".
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Ajax-in-Wicket-next-tp3824240p3825552.html
Sent from t
Hi,
I have created some pretty sophisticated Ajax components for a customer
project using Prototype and JQuery.
I believe client-side JavaScript is becoming more and more reliable, which
means a lot of functionality can be moved from the server side to the
client side.
When creating a sophisticat
2011/9/19 tetsuo
> Ah, one more item in the wishlist is the possibility of joining the many
> js/css resources in one big file. I think it's very hard/impossible to do
> it
> transparently (due the high granularity), but should be relatively easy if
> it required fine-tunning of the app (for exam
Spring-JavaScript (a submodule of Spring WebFlow) used a modular approach,
in which you could (in theory, at least) provide multiple implementations of
a javascript API (
http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch11s03.html
).
You'd import the underlying library (do
On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg wrote:
> here is my take on the areas that need improvement:
>
> * there is a potential to significantly reduce the size of our
> wicket-ajax.js by rebuilding it on top of a js library like jquery
> which provides all the basics such as an ajax pipeli
i think server-side api changes should be minimal unless you heavily
customized the ajax behaviors with regard to what url/scripts they
use...
-igor
On Mon, Sep 19, 2011 at 11:09 AM, tetsuo wrote:
> Ok. I'd add some kind of 'server-side-push/comet/websocket' support to the
> wishlist :)
>
> It c
On Mon, Sep 19, 2011 at 7:11 PM, Igor Vaynberg wrote:
> staged approach is fine, however its step 2 only that will cause
> migration headaches, so this is just delaying the inevitable...
Matej's work is re-work both of client and server side and I think it
will take some time to implement and stab
Ok. I'd add some kind of 'server-side-push/comet/websocket' support to the
wishlist :)
It certainly will break the javascript side, but do you guys think these
improvements could be implemented without breaking (too much) the Java API?
On Mon, Sep 19, 2011 at 2:49 PM, Igor Vaynberg wrote:
> he
here is my take on the areas that need improvement:
* there is a potential to significantly reduce the size of our
wicket-ajax.js by rebuilding it on top of a js library like jquery
which provides all the basics such as an ajax pipeline and
replaceOuterHtml() function.
* currently we use inline at
What is so broken about the current ajax in Wicket, that requires such
rewrite?
On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg wrote:
> staged approach is fine, however its step 2 only that will cause
> migration headaches, so this is just delaying the inevitable...
>
> -igor
>
>
> On Mon, Sep
staged approach is fine, however its step 2 only that will cause
migration headaches, so this is just delaying the inevitable...
-igor
On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov wrote:
> Hi,
>
> In the recent ticket changes by Igor I mentioned few comments that
> Ajax will be re-written f
Hi,
In the recent ticket changes by Igor I mentioned few comments that
Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
call it).
I want to share my experience with trying to re-vive Matej's work at [1], [2].
The changes there are a bit drastic (maybe because the task hasn't
b
33 matches
Mail list logo
