Forgive me if I am wrong, but I thought that unknown annotations must be
ignored by the Java compiler. If not, I stand corrected.
About logging: there is usually too much logging already. Logging is
mostly useful for negative messages. Extracting more information from a
log takes the hours I
it is not a question about storing the entire session or not.
The idea is that the second level cache keeps the session small.
Because if we just rely on the session to serialize by the container
then how many pages or page versions should we keep in memory?
we did see by the AccessStackPageMap
i see this in that behavior:
public void onRendered(Component component) {
super.onRendered(component);
// Append the span and img icon right after the rendering of the
// component. Not as pretty as working with a panel etc, but works
// for behaviors and is more
shouldn't this:
public void updateModel() {
dateField.updateModel();
hoursField.updateModel();
minutesField.updateModel();
amOrPmChoice.updateModel();
if (date != null) {
try {
TimeZone zone = getClientTimeZone();
if
I'd like to apply the fix for issue WICKET-298
(http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The
fix is completely transparent/ doesn't break the API.
Eelco
I'd like to apply the fix for issue WICKET-298
(http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The
fix is completely transparent/ doesn't break the API.
+1
Eelco
Yep. Thanks.
Eelco
On 2/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
shouldn't this:
public void updateModel() {
dateField.updateModel();
hoursField.updateModel();
minutesField.updateModel();
amOrPmChoice.updateModel();
if (date != null) {
So this: left:140px; --
is the difference, correct?
I guess the thing to do here is to append the div and maybe the image
in a separate overridable methods.
Eelco
On 2/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
i see this in that behavior:
public void onRendered(Component component) {
that value is just something that works for my field because that field was
almost that big.
But i don't want it to be after the field, but i want it to be over the
field bu then completely to the right.
But i think we just need to have a over ridable method yes. But what to
extract?
the
Can't you mention the issue in some kind of «release errata»
with a link to JIRA?
Sure. I'll happily keep that for Martijn to do. I'm done with this issue.
Eelco
the question is, how exactly you want to track the changing of focus?
-Matej
Johan Compagner wrote:
if i have an ajax behavior on a text field event: onfocus
and i set the background and then add that component to the ajax event for
redraw
then i loose focus. Ofcourse there are ways to go
Frank, you are using this new datepicker... how do you use it?
Eelco
On 2/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
Filtered! So i couldn't see that nice picture :(
How do you place the field itself? For servoy we use all CSS fixed
positioning
Then it doesn't work. I have to include
if you're installing them explicitly, you have a nice type-safe constructor
with code completion help. and if you do need a config parameter later
you can add it and everyone on earth will know what happened.
igor.vaynberg wrote:
unlike jmx this isnt part of core, so if you dont want to
yes. the generalization is what i'm more afraid of here...
igor.vaynberg wrote:
i guess another thing to consider is that in both of these cases there are
no sideeffects of installing these things. if you dont use the annots
everything is as it was before. so its not like you drop this
h. i'm a bit slow this morning. the reason you want to change
authorization
is because auto module initialization doesn't permit easy parameters to the
module
such as:
add(new WicketModuleAnnotatedRoleSecurity(Application.this, ...));
(or whatever name best fits this module)
Jonathan
+1 but i still think an exception is better
-igor
On 2/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
+1
On 2/19/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I'd like to apply the fix for issue WICKET-298
(http://issues.apache.org/jira/browse/WICKET-298) to Wicket 1.2.x. The
fix is
yes, tracking is easy with our new event thing :)
get on it matej!
-igor
On 2/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
attach an onfocus event on all focusable components
then have a javascript variable in the page that gets that assigned
input type=text
+1
-igor
On 2/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
Any objections now? (for 1.3 and 2.0)
Because you can't remove a behavior from a component and now you
also can't dynamically disabled one either. So thats a bit annoying.
johan
you can have multiple strategies easily working together. just keep looping
through them until you get a false out of one (a veto) and then stop. if no
false then it passes - true. just what a compound strat would do.
but setonce and exception wont work. then module can never set one, so we
lose
we do disagree. i don't believe in the ability of module designers to
create
modules that seamlessly interoperate. we had this problem almost 20 years
ago with windows hooks and it was a complete disaster. i've seen it
repeated
in other places in oo systems and it's a mess there too. i think
yes, on large scale maybe. i am talking about small self-contained modules.
and this isnt really InstallHook :)
not all approaches like this are bad. eclipse/osgi is one example where
there are a ton of tiny modules that work together really well.
-igor
On 2/19/07, Jonathan Locke [EMAIL
not a flag just a overridable method
johan
On 2/19/07, James McLaughlin [EMAIL PROTECTED] wrote:
Fwiw, I would love to have this. But if you are going to add a flag to
disable a behavior, it doesn't seem like too much more work to add a
mechanism to remove it as well.
On 2/19/07, Johan
well we have the new Wicket.Event thing you can use to install events. so
really what you do is create a javascript variable, then install a
'domready' event that traverses the dom tree looks for formcomponents and
adds an onfocus event. then we just need to make the ajax stuff aware of
this.
What i want is this:
component.add(new ajaxbehaviour(onfocus))
then in the onEvent i do
ajaxtarget.add(component)
but then the focus is gone.
So what should happen is that the focus is tracked on the page
and when a ajax request comes back then it does focus() again.
What we also can do is
if you want something specific then you can already do ajaxtarget.focus()
ajaxtarget.appendjavascript(document.getelementbyid
('+c.getmarkupid()+').focus();)
if you want this more general so it works transparently its trickier. then
like you said you need to keep track of focus in a var and
i have no idea if i do it correctly now, i dropped that file (that was
reported here) into my svn dir
But i don't know if that is the right file and if that svn dir is used for
eclipse (using the binary bindings)
johan
On 2/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
* Jean-Baptiste
that would be the best thing
because doing it serverside is a bad thing
because the user could already be jumping to another field and then
it always is restored to the one you think it is on the serverside
The best thing is attaching it on the onfocus event on the client side
and record it.
and
I know you guys have already thought about/discussed this, but can't
you reduce the size of the page map by storing deltas? I thought I
saw a thread about it in the dev list archives... What I'm getting at
is that if you could significantly reduce the size of the page map,
there might not
On 2/19/07, Ryan Holmes [EMAIL PROTECTED] wrote:
I know you guys have already thought about/discussed this, but can't
you reduce the size of the page map by storing deltas? I thought I
saw a thread about it in the dev list archives... What I'm getting at
is that if you could significantly
Hi team,
I'm about to finish porting the MockWebApplication and
WicketTester refactoring that happened in trunk to branch 1.x. Do
you all agree to break the API in branch 1.x WRT WicketTester?
BTW the wiki does not mention the API break:
30 matches
Mail list logo
