Dallas! That's funny. We're both in the States now then. Any chance you'll be near Seattle?
On 11/29/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > Actually I'm in Dallas this week and it is 10pm currently over here. > > > 2. (Probably cheaper, maybe easier) what I suggested: always prepend > > absolute src and href attribute values with /context-path/ as a last > > post processing step. Would that have any real disadvantages? I think > > this should always work, don't you? > > you mean absolut urls without hostname like /myPage.html (a url which > starts with "/") and leave alone all http://xxx/yyy and all relative > paths like myPage.html? Erm. I meant relative src/ href values. thus things like: src="myimage.jpg". There are the ones that cause problems. > > I would rather pre-process than post-process it. Reason: a) we have no > real post-processing and b) if a component decides to change it, > post-processing would possibly modify that as well, which I personally > wouldn't like. a) I think Johan recently added such support to Wicket. Maybe something else to discuss. b) From a components point of view, I agree.. It's kind of dirty to do such post processing. Otoh, it /is/ the only way you can be sure it is done or even needed as beforehand you won't know as components might change the values etc. I think we have to choose between either: * having 'magical' support so that your Wicket pages will keep on working even though you mount them on crazy paths, or * not having out-of-the-box mounting/ nice url support at all and promote the use of Servlet filters for this purpose. As nice urls seem to be a big thing for a lot of people, I tend to sit in the magical support camp. Eelco > > Juergen > > On 11/30/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > Wow, you're up early! > > > > Two choices: > > 1. Components could/ should use a IRequestEncoder's method to get the > > 'prefix'. That way, everything that has to do with 'url translation' > > goes into one implementation > > 2. (Probably cheaper, maybe easier) what I suggested: always prepend > > absolute src and href attribute values with /context-path/ as a last > > post processing step. Would that have any real disadvantages? I think > > this should always work, don't you? > > > > Eelco > > > > > > On 11/29/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > 2) The disadvantage of working with paths is that all images, stylesheets > > > etc > > > get messed up. I think we could and should provide some magic to > > > fix this > > > transparently. Something like a filter that post-processes > > > generated HTML > > > (not only components as there might be a bunch of non-component > > > tags too) > > > and that prepends all relative (not starting with /) href, src, > > > ... attributes > > > with the context path. This <img src="hi.gif" /> would be > > > <img src="/mycontext/hi.gif" /> > > > > > > Juergen, if you are reading this... would this be doable? See any > > > problems > > > with it? > > > > > > > > > I don't think it is difficult, but I find kind of uncomfortable. What > > > I mean by this > > > It is related to the URL handling stuff and should/must not be used in > > > combination with anything else. It is like <wicket:link>, but the > > > behaviour depends on the url strategy. To keep the markup independ on > > > the url strategy, wicket:link implementation must vary; must be > > > customizable. At least it must support two strategies: the current one > > > and "prefix with context path" one. How to decide which one to use? > > > Application settings? Application.getWicketLinkXXX(). > > > > > > Juergen > > > > > > On 11/29/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > All redirect issues i can think of (in Page constructors or in > > > > checkAccess()) are fixed. > > > > They should all work fine again > > > > > > > > johan > > > > > > > > > > > > On 11/29/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > > > Hi Eelco, > > > > > > > > > > Before this refactoring it was possible to redirect to another page > > > > > from inside page.checkAccess(), however since the refactoring it is no > > > > > longer possible. The new page is put on the stack but ignored aftered > > > > > the response of the original page is done. > > > > > Is there a new place where we can intercept a page or is this still > > > > > work in progress? > > > > > > > > > > We are working on a customized version of wicket here (with integrated > > > > > jaas authorization) and i am trying to keep our version in sync with > > > > > head. > > > > > > > > > > Maurice > > > > > > > > > > 2005/11/28, Eelco Hillenius <[EMAIL PROTECTED]>: > > > > > > Hi all, > > > > > > > > > > > > I've been working on some heavy duty refactorings of RequestCycle > > > > > > the > > > > > > last few days. I'm far from done, but I just reached an important > > > > > > milestone in it and I thought it was time to explain a bit what I am > > > > > > doing for those that follow HEAD. > > > > > > > > > > > > There's a TODO document in the new niceurl example of > > > > > > wicket-examples. > > > > > > Juergen, if you're reading this, could you take a look at that? > > > > > > There's a question for you in it :). > > > > > > > > > > > > Here's the last commit log in which I try to explain the > > > > > > refactorings: > > > > > > > > > > > > ... > > > > > > work in progress: request cycle refactoring. > > > > > > > > > > > > Milestone: the major part of low-level refactoring is done now and > > > > > > there is new functionality > > > > > > for mounting request targets to paths. > > > > > > > > > > > > A short explanation how request processing works now: > > > > > > > > > > > > Request cycle processing is now mostly delegated to an instance of > > > > > > IRequestCycleProcessor which can > > > > > > be created by RequestCycles or - preferably - the default request > > > > > > cycle processor in Application. > > > > > > > > > > > > I defined the processing clear steps; they can be found as methods > > > > > > on > > > > > > IRequestCycleProcessor: > > > > > > > > > > > > 1. Destiling a strongly typed RequestParameters object from the > > > > > > Request. This is done by an instance > > > > > > of IRequestEncoder. The request encoder is the strategy that > > > > takes > > > > > > care of creating urls (all urlFor > > > > > > methods of Page are now dispatched to this strategy) and > > > > 'decoding' > > > > > > them into the strongly typed > > > > > > parameters object. Furthermore, the encoder interface > > > > > > provides > > > > for > > > > > > mounting and unmounting > > > > > > Wicket request targets (see 2). Using this interface has the > > > > > > advantage that all 'translations' are now > > > > > > being done by one object and that the translations do not do > > > > > > any > > > > real > > > > > > processing yet. Hence the > > > > > > actual processing can be implemented in a very different way > > > > > > that > > > > has > > > > > > nothing to do with url translations. > > > > > > > > > > > > > > > > > > > > > > > > 2. Solving an incomming request to a request target using the > > > > > > strongly > > > > > > typed RequestParameters of step 1. > > > > > > Request targets (IRequestTarget) are a central concept in > > > > > > the new > > > > > > refactorings. A request cycle has > > > > > > one current request target that can range from a bookmarkable > > > > page > > > > > > (or a redirect to it), a component > > > > > > listener invocation to shared resources, external resources > > > > > > or > > > > > > something like a HTTP error message. > > > > > > Request targets themselves are responsible for creating/ > > > > delegating a > > > > > > response. For the rest they are > > > > > > fairly shallow, and implementations of > > > > > > IRequestCycleProcessor do > > > > the > > > > > > heavy lifting. > > > > > > > > > > > > Once the target is determined, it is set as 'the current' > > > > > > target > > > > in > > > > > > the RequestCycle. Actually, RequestCycle > > > > > > holds a stack of all set targets. For instance, when you call > > > > > > setResponsePage, what happens is that > > > > > > actually a request target implementation (in this case > > > > > > (PageRequestTarget) is put on top of the stack. > > > > > > after the request cycle is done executing, all request > > > > > > targets > > > > will > > > > > > be iterated and their cleanUp methods > > > > > > will be called to enable request target implementations to > > > > > > free > > > > > > resources, give notifications, etc. > > > > > > > > > > > > 3. The next step is event dispatching. During this step things like > > > > > > calling listener interface methods (such > > > > > > as Link.onClick) may be done. > > > > > > > > > > > > 4. The last step is to respond using the current request target. A > > > > > > target may directly call render on e.g. > > > > > > a component, delegate the actual response creation (like with > > > > > > resources) or create a redirect to > > > > > > defer the actual handling. A target implementation is free > > > > > > to do > > > > > > whatever it wants, as long as a response > > > > > > is created. > > > > > > > > > > > > 4.a. when something during handling of 3 or 4 goes wrong, an > > > > > > exception > > > > > > response is created. It is now much > > > > > > easier (I hope) for users to implement completely custom > > > > exception > > > > > > handling/ page rendering. > > > > > > > > > > > > NOTE: most of the refactorings are interface based (due to popular > > > > > > demand?) so that it is much easier than > > > > > > before to create proxies, interleave them, etc. This can now be done > > > > > > better than before as the contract > > > > > > is better externalized now (and enforced in the final method > > > > > > RequestCycle.request()) and devided in seperate > > > > > > steps instead of being implementation details. > > > > > > > > > > > > NOTE: there is a lot of cleaning up to do still. I'd like to take a > > > > > > good look at all the special cases we put in > > > > > > Application/Settings/Pages > > > > > > the last few months, and get rid of the things we don't need to > > > > > > support > > > > anymore > > > > > > when they can be done using this interface, such as exception page > > > > handling. > > > > > > > > > > > > > > > > > > NOTE: there is a default, handy implementation of > > > > > > IRequestCycleProcessor called CompoundRequestCycleProcessor > > > > > > which delegates it's behaviour into seperate interface calls so that > > > > > > it is easier to mix-'n-match implementations. > > > > > > > > > > > > NOTE: there are some API breaks: > > > > > > > > > > > > - Page class alias functionality is not supported anymore. It was > > > > > > 'miss-used' for shortening resource keys > > > > > > more than it was for having page aliases, and while the > > > > shortening of > > > > > > resource keys might be a nice thing > > > > > > to have again in the near future, the page aliases are not > > > > > > needed > > > > > > anymore as it is replaced by the new > > > > > > path mounting functionality. We need to rethink the > > > > > > shortening of > > > > > > resource keys in a more generalized > > > > > > fashion in the next few days. > > > > > > > > > > > > - The home page render strategy is removed. There are now two > > > > > > options: > > > > > > 1. The home page class is mounted to a path. When that is the > > > > case, a > > > > > > redirect to this bookmarkable page > > > > > > path will be issued and the mounted url is thus > > > > > > shown. > > > > > > 2. Nothing was mounted. The home page is rendered directly > > > > > > and > > > > the > > > > > > url will be 'clean' > > > > > > (like > > > > http://localhost:8080/wicket-examples/navomatic ) > > > > > > > > > > > > I know there was a third option, but it was not clear to me > > > > > > what > > > > the > > > > > > advantage for that one was. If someone > > > > > > needs it, please complain :) > > > > > > > > > > > > ... > > > > > > > > > > > > Hope you have fun with it. Tomorrow, I'll (finally, sorry Evan) > > > > > > implement browser detection, which should be fairly simple now. > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through > > > > > > log > > > > files > > > > > > for problems? Stop! Download the new AJAX search engine that makes > > > > > > searching your log files as easy as surfing the web. DOWNLOAD > > > > > > SPLUNK! > > > > > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick > > > > > > _______________________________________________ > > > > > > Wicket-develop mailing list > > > > > > [email protected] > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > > > files > > > > > for problems? Stop! Download the new AJAX search engine that makes > > > > > searching your log files as easy as surfing the web. DOWNLOAD > > > > > SPLUNK! > > > > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick > > > > > _______________________________________________ > > > > > Wicket-develop mailing list > > > > > [email protected] > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > > files > > > for problems? Stop! Download the new AJAX search engine that makes > > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick > > > _______________________________________________ > > > Wicket-develop mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick > > _______________________________________________ > > Wicket-develop mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
