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.
sure
On Tue, Sep 20, 2011 at 12:33 PM, Martin Grigorov wrote:
> you asked for something and I asked for something else
> do we have an agreement ? :-)
>
> On Tue, Sep 20, 2011 at 10:21 PM, Igor Vaynberg
> wrote:
>> or copy the relevant bits of the issue into the javadoc of the test...
>>
>> -ig
you asked for something and I asked for something else
do we have an agreement ? :-)
On Tue, Sep 20, 2011 at 10:21 PM, Igor Vaynberg wrote:
> or copy the relevant bits of the issue into the javadoc of the test...
>
> -igor
>
> On Tue, Sep 20, 2011 at 11:55 AM, Martin Grigorov
> wrote:
>> OK, I'
or copy the relevant bits of the issue into the javadoc of the test...
-igor
On Tue, Sep 20, 2011 at 11:55 AM, Martin Grigorov wrote:
> OK, I'll rename them.
>
> Maybe it is just me but I find the information in the tickets very
> useful so I'd like also to ask for something - add more informati
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
OK, I'll rename them.
Maybe it is just me but I find the information in the tickets very
useful so I'd like also to ask for something - add more information to
tickets' description and link from the test's javadoc to the ticket it
fixes.
Thanks!
On Tue, Sep 20, 2011 at 7:36 PM, Igor Vaynberg wr
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
This vote is to release wicket 1.5.1
Branch
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5.1
Artifacts
http://people.apache.org/~ivaynberg/wicket-1.5.1/dist/
Maven repo
https://repository.apache.org/content/repositories/orgapachewicket-081/
Changelog
https://issues.apache.org/jira/s
can we please not do this:
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/wicket4066/Wicket4066Test.java
wicket/intercept is a much more descriptive package name
InterceptBackToHomePageTest is a much more descriptive class name
i hate to go to jira to look up what 4066 was when i brea
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'
On Tue, Sep 20, 2011 at 3:02 AM, wrote:
> Author: ivaynberg
> Date: Tue Sep 20 00:02:06 2011
> New Revision: 1172909
>
> URL: http://svn.apache.org/viewvc?rev=1172909&view=rev
> Log: (empty)
>
> Modified:
> wicket/trunk/wicket-core/src/main/java/org/apache/wicket/Behaviors.java
>
> wicket/
25 matches
Mail list logo
