Re: Any objection to adding RequestCycle#getRequestTargetStack()?
the reason is that we are exposing the fact that there is a stack. if we wanted to reimplement this later without a stack we would not be able to without api breaks. i dont feel strongly about it because i dont think we are likely to reimplement the thing, so do whatever you want. -igor On Fri, Dec 17, 2010 at 8:45 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Fri, Dec 17, 2010 at 12:28 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: why? Someone asked me about it, and although I think there are better ways, I couldn't see a reason that we shouldn't allow access, and wondered what others thought. The reason was for some kind of in-depth request logger that could log not only what was originally requested, but what eventually actually ended up being the response. i.e., look at the request target stack and see that the original request target was a form submission on page X, and last target was a page request target for Y, or a download target, etc -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Moving wicket stuff to github
So we're all set and currently running a test import. Once we validate that the test import is correct, we'll do the final import. Unless there's a disaster/major concern I'd like to propose to do the migration next wednesday (dec 22nd 2010). Any objections to this date? If you want to test the svn import, take a look at the https://github.com/wicketstuff/testofwicketstuffsvnimport/ test repository. Note that any commits done to that repository *will* be nuked, but it would be nice to check if that works as well :) The import is running, and will take some time to complete. So you might not see anything in the repository for a while. Martijn On Thu, Dec 16, 2010 at 5:04 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I've claimed an organization for Wicket Stuff: https://github.com/wicketstuff and we can create multiple repos under that, and create and assign different teams to the repositories. How we organize things is just a matter of this debate ;) I have put a redirect from apache extras - wicket stuff - github, so we don't get fragmented. I'm going to look into doing something similar to the sf.net project (but after we have moved everything over) Next we need to discuss how to migrate everything over. Are we going to move whole wicketstuff over to one repo, or a git repo per project (where wicketstuff core counts as one project)? Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: [jira] Resolved: (WICKET-3218) Component#onInitialize is broken for Pages
On Fri, 17 Dec 2010 11:05:01 -0500 (EST)
Igor Vaynberg (JIRA) j...@apache.org wrote:
i made the decision to make the method final in page. i think this
makes more sense then delaying the call because by the time the
page's constructor is finished the page should be initialized, eg
code like this is commong
EditUserPage page=new EditUserPage(user);
page.switchToAddressEditMode();
switchToAddressEditMode() may depend on certain components being
added to the hierarchy and if they are added in oninitialize() which
is delayed the method may fail.
thus, the principle of least surprise dictates we make it final in
page.
Well if your superclass is doing things you don't know about then you
are usually screwed anyway. Is this case really that common? Making it
final at least makes it obvious that onInitialize doesn't work, however:
It leaves a question open: What is the official approach
that replaces onInitialize for a page? What if I want to provide an
extension point for sub-pages but still need to give them a chance to
have their own constructor run first?
Typical example with panel-based layout in a super page:
class AbstractLayoutPage {
public AbstractLayoutPage() {
add(getLeftColumn());
add(getRightColumn());
}
protected Component getLeftColumn() {...}
protected Component getRightColumn() {...}
}
class SomeConcretePage {
private final Object someImportantObject;
public SomeConcretePage(Object o) {
this.someImportantObject = o;
}
@Override protected Component getLeftColumn() {
return new CustomLeftColumn(this.someImportantObject);
// fails because someImportantObject isn't initialized.
}
}
With a delayed onInitialize (or my original proposal for a separate
onPageInitialize) I could do this in onInitialize. Right now I have
no way of doing this safely. How can I have an initialization in page
after the constructors are done? Without some sort of change to
onInitialize or a new event entirely I only see doing it in
onBeforeRender and manually keeping track of whether it's been done
already or not.
Personally I have seen the overridable Panel approach much more often
than hoping without looking that the superclass does its construction in
a particular order.
I'm not saying that my patch is the perfect solution - but I'd really
like an official hint at how to do something after the page
constructors.
Thanks
Carl-Eric
www.wicketbuch.de
Re: svn commit: r1050581 - in /wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation: AbstractDependencyRespectingResourceAggregatingHeaderResponse.java AbstractResourceAggregatingH
Any objections to me making this same change in 1.4.x? It would be an API
break, but on code that only appeared in the last release (1.4.14), and I
highly doubt anyone is using it yet.
I could, of course, add a backwards-compatible method, but it seems like
that's overkill for this brand new thing.
On Fri, Dec 17, 2010 at 9:32 PM, jrthomer...@apache.org wrote:
Author: jrthomerson
Date: Sat Dec 18 03:32:37 2010
New Revision: 1050581
URL: http://svn.apache.org/viewvc?rev=1050581view=rev
Log:
slight improvement to api of AbstractResourceAggregatingHeaderResponse.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java?rev=1050581r1=1050580r2=1050581view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
Sat Dec 18 03:32:37 2010
@@ -66,7 +66,7 @@ public abstract class AbstractDependency
if (ref instanceof
AbstractResourceDependentResourceReference)
{
AbstractResourceDependentResourceReference
parent = (AbstractResourceDependentResourceReference)ref;
- R childColl =
newResourceReferenceCollection();
+ R childColl =
newResourceReferenceCollection(key);
for
(AbstractResourceDependentResourceReference child :
parent.getDependentResourceReferences())
{
childColl.add(toData(child));
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java?rev=1050581r1=1050580r2=1050581view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
Sat Dec 18 03:32:37 2010
@@ -46,10 +46,10 @@ import org.apache.wicket.resource.Resour
* @author Jeremy Thomerson
* @param R
*the type of ResourceReferenceCollection returned by
- *{...@link #newResourceReferenceCollection()} and passed to all
the methods that take a
- *ResourceReferenceCollection. You will typically just use
ResourceReferenceCollection
- *for this param, unless you are returning a specific type of
- *ResourceReferenceCollection from your subclass.
+ *{...@link #newResourceReferenceCollection(Object)} and passed
to all the methods that
+ *take a ResourceReferenceCollection. You will typically just
use
+ *ResourceReferenceCollection for this param, unless you are
returning a specific type
+ *of ResourceReferenceCollection from your subclass.
* @param K
*the class of the key that you will create from
*{...@link #newGroupingKey(ResourceReferenceAndStringData)}
@@ -107,7 +107,7 @@ public abstract class AbstractResourceAg
R coll = map.get(key);
if (coll == null)
{
- map.put(key, coll =
newResourceReferenceCollection());
+ map.put(key, coll =
newResourceReferenceCollection(key));
}
coll.add(ref);
}
@@ -135,10 +135,13 @@ public abstract class AbstractResourceAg
* parameter used when creating your subclass defining the type of
ResourceReferenceCollection
* this returns and is passed into all methods that take a
ResourceReferenceCollection
*
+* @param key
+*the grouping key that will be used for this
collection. all references added to it
+*will have the same key
* @return a newly
