Re: Wicketstuff - Openlayers: not working with wicket 1.5.5?
> final Layer layerOSMTilesAtHome = new OSM("Osmarender",
> OSMLayer.TilesAtHome);
The "Osmarender" renderer became unavailable recently (not sure why).
Comment out the lines that refer to it, and to "layerOSMTilesAtHome".
This has nothing to do with Wicket.
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
datazuul said:
> Hi I tried to embed an openstreetmap in my page with the code from
> SimpleOpenStreetMapPage (wicketstuff openlayers example):
>
> final List layers = new ArrayList();
>
> final Layer layerOSMTilesAtHome = new OSM("Osmarender",
> OSMLayer.TilesAtHome);
> final Layer layerOSMMapnik = new OSM("Mapnik", OSMLayer.Mapnik);
> final Layer layerOSMCycleMap = new OSM("CycleMap", OSMLayer.CycleMap);
>
> layers.add(layerOSMMapnik);
> layers.add(layerOSMTilesAtHome);
> layers.add(layerOSMCycleMap);
>
> final HashMap mapOptions = new HashMap String>();
> final Bounds boundsExtend = new Bounds(new LonLat(-20037508.34,
> -20037508.34), new LonLat(20037508.34,
> 20037508.34));
> mapOptions.put("maxExtent", boundsExtend.getJSconstructor());
> mapOptions.put("projection", "new
> OpenLayers.Projection('EPSG:900913')");
> mapOptions.put("displayProjection", "new
> OpenLayers.Projection('EPSG:4326')");
> mapOptions.put("units", "'meters'");
> mapOptions.put("maxResolution", "156543");
> mapOptions.put("numZoomLevels", "18");
>
> final OpenLayersMap map = new OpenLayersMap("map", true, layers,
> mapOptions);
>
> map.addControl(Control.LayerSwitcher);
> map.addControl(Control.MousePosition);
> map.addControl(Control.KeyboardDefaults);
>
> // map.setCenter(new LonLat(10.2, 48.9));
> // map.setZoom(3);
>
> add(map);
>
> but nothing is rendered.
>
> Javascript error:
> Error: OpenLayers.Layer.OSM.Osmarender is not a constructor
> Line: var osm26507926 =new OpenLayers.Layer.OSM.Osmarender('Osmarender');
>
> Anyone using OpenLayersMap and knows how to get it working?
>
> (I already tried this fix, mentioned by another user:
> private static final String OPEN_LAYERS_VERSION = "2.11"; in OpenLayersMap,
> didn't help)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Upgrade from 1.4 to 1.5: timeframe?
Hi Natalie, > I'm finally coming up on upgrading from 1.4.19 to 1.5. To manage my projects > better, could anybody comment on how long it took them to upgrade? I know it > depends on how "complicated" your application is, but as a general > guideline, does it take minutes, days, months? It took me roughly 3 weeks to upgrade from 1.3 to 1.5. The biggest problems to deal with were: (a) Pages no longer cacheable, which makes the app sluggish. (Maybe this was already the case in 1.4.) (b) The new version numbering scheme that's exposed in the URL, ?4 ?5, ... which looks awful if you like clean URLs. (c) A bug in cookie handling, which took several days to report: https://issues.apache.org/jira/browse/WICKET-4358 My solution for (a) and (b) was to move to static pages. This took some time, but I think static pages bring other advantages, so it was probably time well spent. The top-level code is here: http://zelea.com/project/votorola/s/wic/ -- Michael Allan Toronto, +1 416-699-9528 http://zelea.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: To enable client-side page caching
PPS, This isn't enough: > > ... Is there an API to re-enable caching? Or do I set > > the response headers myself? > > Sorry, I see the answer is WebResponse.enableCaching() ... You must also override WebPage.setHeaders(). It isn't documented so I updated the wiki and opened a bug on the 1.5.4 API: https://cwiki.apache.org/WICKET/caching-in-wicket-15.html https://issues.apache.org/jira/browse/WICKET-4357 -- Michael Allan Toronto, +1 416-699-9528 http://zelea.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: To enable client-side page caching
> We do a lot of back-and-forth navigation and I'd like to keep it light > and responsive. Is there an API to re-enable caching? Or do I set > the response headers myself? Sorry, I see the answer is WebResponse.enableCaching(). Just this question, then: > Should I expect any problems? Again, I'm not sure it makes a > difference, but this is only for pages that pass the > @StatelessComponent test. -- Michael Allan Toronto, +1 416-699-9528 http://zelea.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
To enable client-side page caching
I'd like to enable client-side page caching for stateless pages. I'm migrating from 1.3 to 1.5 and the migration guide says, "All Wicket pages are by default non-cacheable as in 1.4". https://cwiki.apache.org/WICKET/caching-in-wicket-15.html We do a lot of back-and-forth navigation and I'd like to keep it light and responsive. Is there an API to re-enable caching? Or do I set the response headers myself? Should I expect any problems? Again, I'm not sure it makes a difference, but this is only for pages that pass the @StatelessComponent test. -- Michael Allan Toronto, +1 416-699-9528 http://zelea.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Running a huge wicket site(1m + users)
> We are having the potential fun of running a site with around 1 million > users, and a lot more over time. What could be great optimizing points? Don't bother guessing. Attach a good profiler and discover where the bottlenecks *actually* are. Then fix them, one by one. (Afterwards, tell us what you've learned, and we'll see who guessed right. ;) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
[EMAIL PROTECTED] wrote: > Yes, you can have EJBs calls over HTTP. Google for HTTPInvoker. It's a > component from JBoss. Ah, you lucky EJB guys - you're on top of it already. > That's what makes the Genesis framework so interesting: > http://genesis.dev.java.net "...to allow people with little knowledge of the Java platform to develop robust applications fast, without requiring them to learn several new technologies and complex concepts." In just six days. And on the seventh, they rest. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Johan Compagner wrote: > You guys want a Tunnel library that can tunnel RMI over http? > > http://sebster.com/tunnel/ > > works fine. We use it in our product Excellent, that's exactly what's needed. "... multiplexed RMI Socket Factories ... together with the HTTP tunnel this allows you to use bidirectional RMI over the internet, without having to worry about firewalls, HTTP proxies, or NAT routers." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
Zappaterrini, Larry wrote: > > Your reason is a special instance of a much more general reason. Web > applications are much easier to deal with from a deployment > perspective than desktop applications. I don't know, it's not difficult to set up an RMI server, or to deploy a Swing client with Web Start (gives the user a single-click launch from the browser). I've done it, and frankly it's easier than messing with Tomcat and Web frameworks (no offense to Wicket). And any developer who's coded a GUI using a proper toolkit, such as Swing, will never willingly trade it for a Web framework. (A big part of the attraction of Wicket is its Swing-like, component design. But it can't approach the real thing.) > Also, there are firewall and security issues surrounding access to > central data repositories that web applications handle nicely. That security coddling is a mixed blessing. The browser's sandbox, for instance, makes it a complicated business to provide the user with normal access to resources on the desktop. With Swing, your app is a full peer on the desktop. True, there are firewall and NAT hurdles for RMI clients. I googled for "RMI over HTTP" and "HTTP tunneling", and I didn't get a comfortable, reassuring response. Why is that? It's a mystery... It should be a well beaten path. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Tree with Swing DefaultMutableTreeNode
Can't answser the Wicket side, but consider: a) Swing is not thread-safe b) it is often better to code your own TreeNode as a bridge to the underlying reality (Wicket's models?); rather than using DefaultMutableTreeNode, which is a full-blown model in itself -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
why are we coding Web apps?
Daan van Etten wrote: > >> Yeah I know, problem are that our application are ajax heavy, and >> stateless and ajax does not cope well I've heard.. > > Maybe not within Wicket, I know too little of Wicket to draw a valid > conclusion on that. But it is definitely possible. > Look for example at the SproutCore development model. They create their > application in Javascript and do requests to the backend to get records, > save records, etc. Their application runs in the browser, making the server > more like a stateless backend (from what I understood of SproutCore). > I know it's possible (and done before) to build a Javascript application > (or even desktop) that way. I'd rephrase that to: "... build a desktop application, or even a Javascript application (if you are into pain)" You are generalizing beyond a traditional Web architecture (as Wicket supports), and that opens the field to other client/server architectures, in addition to the Web. And I can't think of a reason for coding a Web client, except this one: 1. The user can seamlessly click into the application from external sites, and click back out again. Can anyone think of another reason? Because otherwise, if I have an app that doesn't need cross-hyperlinks with the larger Web, then why should I code it as a Web app in the first place? Shouldn't I code the front end as a proper GUI, using a framework like Swing? I'm asking myself this question. And in my case I come up with one additional reason, which is just a special case of (1): 1 a. A Web client is good for demonstrating a new application, because it's convenient for casual users, who wish to try out the app. Most users have Web browsers pre-installed. They may not have Java, etc. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session question
Eyal wrote: > isn't volatile will create overhead on the Session? > Read this: http://www.javaperformancetuning.com/news/qotm030.shtml Any overhead is essential, Eyal. You *want* threads to flush their memory caches, when accessing session variables. Otherwise, variable changes by one thread might be invisible to others. (Alternatively, you can sync. But the overhead is probably higher.) -- Michael Allan http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session question
> Is putting a field in a Session and call it makes the session "work to > hard"? > I'm not a web expert so maybe my question is naive, but does calling for a > field in a Wicket Session creates overload in the net? No, it is common practice, in general. Search the list for 'session' and 'field'. (And maybe for 'thread-safe'. You probably want the field to be volatile.) -- Michael Allan http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to detect model changes in form submission
> Is there an easy way to detect what model objects have changed as a result of > a form submission? I see that wicket compares the old values to the > submitted values but where can I hook into tthat change detection? I have a > data grid with many rows and only a few could change. Override IModel.setObject(object) in a model subclass. Have it set a boolean flag isChanged. Remember to clear the flag, after you read it, and act on it. -- Michael Allan http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket cheat sheet, solve your wicket problem fast?
Nino Saturnino Martinez Vazquez Wael wrote: >>>> That page is so ridden with ad-spam, Nino, there's no visible content! >>> >>> argh! It's very clean on the upload side of stuff. Anyway when we get >>> confluence sorted out i'll put the diagram on this page : >>> >>> http://cwiki.apache.org/confluence/display/WICKET/Wicket+Cheat+Sheet This works, thanks. ^ >> Or you could try this: >> >> I think it's a direct link : >> http://www20.flyupload.com/dl?fid=9436254&x=9hfpy_sVT1WmQM_gAqdMeQ.. But this is worse than the previous link. ^ It only offers me a prize of $1500. :( -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket cheat sheet, solve your wicket problem fast?
Nino Saturnino Martinez Vazquez Wael wrote: > I've created a small wicket cheat sheet for issues and features, please see > here : http://www.flyupload.com/?fid=9436254 > > ...Any comment will be welcome:) That page is so ridden with ad-spam, Nino, there's no visible content! My browser blocked 3 popup windows. Then an Ajax window floated out, informing me I won $3,000. Behind it, are 4 banner ads, nearly obscuring some Google text ads - so many ads, altogether, they spill over the edges of the screen. I'm surprised that your message got a response from people. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Link string conditionally?
Erik van Oosten wrote: > The idea is to put a span inside the a, and then attach a Label to the > span. Fearing a span-demic in my code, I came up with this: http://zelea.com/project/votorola/g/servlet/BookmarkablePageLinkX.java http://zelea.com/project/votorola/_/javadoc/votorola/g/servlet/BookmarkablePageLinkX.html There's probably a more elegant way to code it, though. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: > Right... I think I'd just invert that, so that the "page" asked for the > stateful data when needed. Yes, that's the only way. The page can easily store the state (and you might rather it did) but it has to be pulled in, not pushed. The general rule is: no external thread can hold a reference to a Wicket model or view, because the model or view is apt, at any moment, to be serialized out of memory. (Restrictions like this must be obvious to a Web developer, but they're counter-intuitive to an old Swing hand.) Similar restrictions apply to the Session (as James was cautioning), because it too is serialized. Furthermore, the Session is not synchronized by the request thread. So code your Session subclass with thread safety in mind. Also code the Application with thread safety in mind. The Application is never serialized, however, so external threads can hold a live reference to it. Finally, clustering affects the environment (including the Application) that pages and components can expect when they pull state. (But maybe this is obvious.) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Johan Compagner wrote: > yes in a clustered environment you have multiply instances of the > Application > because there are more instances of the WicketServlet. > And Application/Servlet context stuff are not replicated Thanks Johan, I've documented Wicket's thread safety (as I understand it) using annotations in my code. Here's the relevant page from my API: http://zelea.com/project/votorola/_/javadoc/votorola/a/web/VPage.html Thanks for the help, gents, -- Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: > I didn't know people were even following it :) Small town, :) I'm working on something similar. > I can tell you now that I only *wish* we had used something like Wicket for > LobbyThem... Ruby on Rails was the biggest mistake we made as I can attest > to 8 months after the event. In fact I think we'd be a lot further along now > if we had used Wicket (or even plain old PHP)! It's impossible to get it right, on the first pass. If it's anything new, it takes multiple iterations - how many, anybody's guess. Wicket is saving me time. It's plain Java and HTML - that was the initial attraction. I can work it under the hood, if necessary. But the real time saver, it turns out, has been this list. The code's well supported by its developers. They meet the users half way. (Now, if I can do that in my own projects, that might be the key.) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Account Activation Email generation and response processing: any design example?
Sam Stainsby wrote: > > Martin Makundi wrote: > > The benefit in digest is that the user (or another user) cannot > > fabricate it... so easily. > > Just send a large random number ... no need for expensive hash > operations. But use java.security.SecureRandom, not java.util.Random. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: > > ... So non-Wicket threads cannot generally access pages, > > components, models, and so forth - not safely. True? > > > I was trying to think of a use-case for that problem... Do you have a > specific use-case or is that just a potential issue you can think of? I'm thinking generally of state changes that occur in separate processes, changes that need to be presented in Web views. Specifically, I have a Web page that shows recent user activity, in a list view, where each element is a user activity event. Not all of my users are Web users, so the underlying list model is receiving events from other processes (mailer daemon, and so forth). Johan Compagner wrote: > Accessing pages in other threads then the request thread is very bad idea. > Because http session object shouldnt be touched between requests, you > have no idea what the container does with your page/session. Store it > on disc, replicate it to other nodes. Of course, now I understand... I was forgetting that instances of these things - pages, components and models - are apt to be serialized out of memory. Non-Wicket threads can't even hold a reference to them. So there's no point in exposing the page lock for other threads (as I suggested). > If you want to do stuff in background threads then let page/request > threads poll them if they are finished. Then the underlying list model (in my example, above) does not belong in the page; instead it belongs in the Application instance. There it can safely register with other threads, and receive events from them, because the app will never be serialized out of memory. And the list view (in the page) can hook up with the model (in the app), at request time, with appropriate synchronization - polling it, as you say. My only other question, then, is the app life cycle. (This article doesn't really answer my Q: http://cwiki.apache.org/WICKET/lifecycle-of-a-wicket-application.html In a clustered environment, are there multiple instances of the app? Might the page (the one with the list view, for example) find itself connecting to a different instance of the app, a different instance of the list model, from request to request? In a non-clustered environment, can I safely assume a single instance of the app, at any given time? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Jonathan Locke wrote: > ... the overall design is single-threaded, meaning you should not > need to provide synchronization ... Is there some specific problem > you have run into? No, nothing specific yet - just a general foreboding of future problems - having been bitten, before. Johan Compagner wrote: > Pages are threadsafe and that is not done by a big sync block, but by > placing a barrier. See Session.getPage() there there is code that > makes sure that 1 thread at a time gets a page from the session the > rest just has to wait Thanks Johan, that's the info I needed. It looks like Session.getPage() is implementing an independent locking mechanism, similar to java.util.concurrent.locks.Lock (JDK 1.5). One possible problem - not affecting me yet, but just to be clear - no access to the page lock (no official API) is provided for non-Wicket threads. So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? When the core framework moves to 1.5, maybe the page locking can be improved. Maybe each Page could have its own standard Lock, and could publish it as Page.lock(). Thread-safety of pages, components, models, and so forth, could then be documented as "must hold Page.lock()". Internal code could check compliance, with: assert page.lock().isHeldByCurrentThread(); Just a suggestion - I'm happy with Wicket as it is, -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: > Does that mean that under heavy load, hitting the index page for instance, I > can expect clients to block as each request is processed? Let me guess... The answer is no? Each session will have its own instance of the index page. Threads of other sessions (other users) will never try to access it. PS - What are you indexing, Brill? Is it a political app, like "Lobby Them"? (Just being nosey... :) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Thread safety for components
I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion "Wicket Session and threading": http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: > Yes. We try our best to make pages/ components as thread safe as > possible... > > > Is there anywhere a small piece on how to deal with threading within > > Wicket (i.e., what is/is not synchronized in a request/response > > roundtrip?). I did some quick searching in the mailing list archives and > > google, but could not find anything related to version 1.3. > > Pages are synced on pagemaps, which basically relates to browser > windows. RequestCycles are separate instances which are not reused, so > no sync needed there. Sessions are not synced so you need to sync > manually. Though in practice this wouldn't give much trouble to start > with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is session.dirty() for?
Matej Knopp wrote: > Martin Makundi wrote: > > > > Let's say I have some variables in my session. If these variables > > change, do I have to call session.dirty? > > If you subclassed the Session class and your attributes are properties > of the subclass. > > But you are required to call session.dirty() only if your pages are > stateless and your application is deployed on cluster. Just to cover all eventualities, Matej (in case we later move to a cluster) is there any harm in *always* calling session.dirty(), when a Session field changes value? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
