Re: A safer way to build PropertyModels, version 1.2
On Jul 28, 2011, at 3:12 AM, Carl-Eric Menzel wrote: IModelUser userModel = model(fromService(userEJB.loadUser(42))); Not sure if this is a typo in your example, but wouldn't this mean that (the real, non-proxied) userEJB.loadUser is invoked when the model is constructed? Perhaps this syntax is correct: model(fromService(userEJB).loadUser(42)); - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: A safer way to build PropertyModels
This looks fantastic. Can you think of an elegant way to use similar syntactic
sugar to create LoadableDetachableModels as well?
For example:
// This would return a PropertyModel
model(from(myBean).getChild().getName());
// This a LoadableDetachableModel
loadedModel(from(myService).listUsers());
// Which is more concise than
new LoadableDetachableModelListUser {
protected ListUser load() {
myService.listUsers();
}
}
On Jul 21, 2011, at 11:45 AM, Carl-Eric Menzel wrote:
After seeing the LambdaJ-based model idea at
https://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-LambdaJ
I thought I'd try and implement something like that in a ready-to-use
fashion, and simplify it a little.
The result is here:
https://github.com/duesenklipper/wicket-safemodel
This is a way to refactor-safely and type-safely build models, without
relying on brittle string literals:
SomeBean myBean = ...
IModelString childNameModel =
model(from(myBean).getChild().getName());
No cast, no string literal, only getters. It works with regular
JavaBeans, Lists, and with Maps (string keys only though).
Instead of requiring a compile-time step this does some proxying in the
background to construct a property expression.
Anybody interested please give it a try and let me know of any issues.
Note: If you feel comfortable with configuring an annotation
processor in your Maven build as well as your IDE build, go ahead and
try Igor's metagen [https://github.com/42Lines/metagen]. That way you
don't have any runtime magic.
Use SafeModel if you don't want an additional compile step and do want
(very slightly) less keyboard typing.
Carl-Eric
www.wicketbuch.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource auto-reload with the Quickstart project
Hmm. I would expect that your LoginPage would see changes reflected when you hit the browser refresh button. Sounds like a bug to me. Is it related to this one? https://issues.apache.org/jira/browse/WICKET-3891 On Jul 13, 2011, at 12:10 PM, Andrew Todd wrote: On Wed, Jul 13, 2011 at 2:40 PM, Matt Brictson m...@55minutes.com wrote: FWIW I tried 1.5-SNAPSHOT and the HTML resource reloading seems to work fine. I'm seeing reloading working as expected on the basic HomePage. However, on a LoginPage that I'm working on, a I do not see changes reflected until I go to the URL bar, go to the home page URL, then go back to the URL and manually enter the Login Page URL (which I've set up with mountPage). Is this related to the way that Wicket handles sessions -- I've seen the word version passed around -- or is this a bug? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource auto-reload with the Quickstart project
The way I've always done it (and this works just fine outside of Eclipse as
well), is to enable resource polling in Wicket for the directory that contains
the HTML files.
In the init() method of your WebApplication subclass (in the quickstart this is
called WicketApplication.java) do something like this:
getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND);
String htmlDir = getServletContext().getRealPath(/);
if(htmlDir != null !htmlDir.endsWith(/))
{
htmlDir += /;
}
getResourceSettings().addResourceFolder(htmlDir + ../java);
getResourceSettings().addResourceFolder(htmlDir + ../resources);
You can find this code and some other best practices in my company's source
repo here:
http://opensource.55minutes.com/svn/java/trunk/fiftyfive-wicket/fiftyfive-wicket-core/src/main/java/fiftyfive/wicket/FoundationApplication.java
--
Matt
On Jul 13, 2011, at 8:32 AM, Andrew Todd wrote:
Hello,
I'm investigating writing a new project in Wicket and am playing
around with a project created from the 1.5-RC5.1 quickstart maven
archetype.
Using 'mvn jetty:run' from the command-line, none of the changes I
make to source files, either Java or HTML, are picked up unless I
restart the server.
Using the instructions here:
https://cwiki.apache.org/WICKET/maven-jetty-plugin.html
I can attach to the Jetty instance from Eclipse, and changes to Java
files, but not HTML files, are picked up on the server.
However, development mode promises automatic reloading of source
files. I need this to work without having to attach to an IDE in debug
mode, and for HTML as well as Java. What am I missing?
Thanks,
Andrew
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource auto-reload with the Quickstart project
Just to clarify, the resource polling should allow you to see HTML changes (but
note Martin's comment about this potentially being broken in 1.5RC1). It does
not affect Java reloading.
For Java changes I believe this is not possible without an IDE or perhaps a
commercial product like JRebel[1]. For Eclipse, the way I've seen it done is to
create a class like the Start.java that comes with the quickstart, right click
on that class, and choose Debug. This will launch a Jetty container inside
Eclipse's debugger, which gives you auto-reloading of Java files.
[1]: http://www.zeroturnaround.com/jrebel/
--
Matt
On Jul 13, 2011, at 10:37 AM, Andrew Todd wrote:
On Wed, Jul 13, 2011 at 1:04 PM, Matt Brictson m...@55minutes.com wrote:
The way I've always done it (and this works just fine outside of Eclipse as
well), is to enable resource polling in Wicket for the directory that
contains the HTML files.
In the init() method of your WebApplication subclass (in the quickstart this
is called WicketApplication.java) do something like this:
getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND);
String htmlDir = getServletContext().getRealPath(/);
if(htmlDir != null !htmlDir.endsWith(/))
{
htmlDir += /;
}
getResourceSettings().addResourceFolder(htmlDir + ../java);
getResourceSettings().addResourceFolder(htmlDir + ../resources);
Thanks for the link. I added this code to init() and confirmed that
the paths being added are the correct ones for my Maven project.
However, I'm still not seeing HTML changes being updated when I do a
'mvn jetty:run.' (Or Java changes, for that matter). Resources in the
htmlDir that was already set, like CSS, are also not updating.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource auto-reload with the Quickstart project
Yes, it is possible configure the jetty plugin to completely redeploy the webapp when it detects a class file has changed, but this isn't quite the same as what the Eclipse IDE and JRebel do. JRebel's site says: instantly see any code change made to an app *without* redeploying. In my experience jetty's redeploy leads to memory being exhausted after the 4th or 5th redeploy. This is not jetty's fault, but simply because it is notoriously difficult to completely eliminate classloader leaks when building webapps. YMMV. -- Matt On Jul 13, 2011, at 11:03 AM, Martin Grigorov wrote: It is possible but you have to extend maven-jetty-plugin's configuration. There was something about Scanner. Ask Google for more info - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource auto-reload with the Quickstart project
FWIW I tried 1.5-SNAPSHOT and the HTML resource reloading seems to work fine. Here's what I did: 1. Generated a quickstart[1] using 1.5-SNAPSHOT using the -U maven option to ensure the very latest snapshot was downloaded. 2. Pasted in the resource polling code into WicketApplication#init[2]. 3. Ran mvn jetty:run. 4. While jetty was running, I edited Home.html: I changed Congratulations to Testing. 5. Hit refresh in my browser and the change showed up. [1]: http://wicket.apache.org/start/quickstart.html [2]: http://apache-wicket.1842946.n4.nabble.com/Resource-auto-reload-with-the-Quickstart-project-tp3665329p3665543.html -- Matt On Jul 13, 2011, at 11:27 AM, Andrew Todd wrote: With the latest snapshot, I still wasn't seeing changes propagate. Until -- On Wed, Jul 13, 2011 at 2:03 PM, Martin Grigorov mgrigo...@apache.org wrote: It is possible but you have to extend maven-jetty-plugin's configuration. There was something about Scanner. Ask Google for more info Adding the scanIntervalSeconds configuration parameter to the Jetty plugin, as per http://stackoverflow.com/questions/2369851/hot-deploy-in-embedded-jetty suddenly changes in Java and HTML were picked up. Eclipse is set to auto-build, so I don't have to explicitly run 'mvn compile' for it to redeploy. However Matt's reply, which just came in, is correct that JRebel is doing something different. The answer seems to be that 1) HTML reload may still be broken in SNAPSHOT 2) For making changes to Java code, run in Debug mode and connect with an IDE, or use JRebel Thanks, Andrew - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicketstuff.org/maven is down - trying to get wicketstuff-merged-resources
Hello list, I am trying to download wicketstuff-merged-resources-3.0.jar, which until recently was available in the wicketstuff.org maven repository here: http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-merged-resources/3.0/wicketstuff-merged-resources-3.0.jar Is this a temporary glitch, or has this repository been shut down? I've also tried maven central and oss.sonatype.org, and while these repositories do have other wicketstuff artifacts, they do not have wicketstuff-merged-resources-3.0. Is there a reliable maven repo for wicketstuff-merged-resources? Thanks. -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Fate of CompressedResourceReference in Wicket 1.5?
Opened: https://issues.apache.org/jira/browse/WICKET-3526 -- Matt On Mar 9, 2011, at 11:02 PM, Martin Grigorov wrote: File a ticket please. On Thu, Mar 10, 2011 at 3:01 AM, Matt Brictson m...@55minutes.com wrote: Hi, CompressedResourceReference in trunk is basically empty and has the comment TODO NG. A quick search through the source leads me to believe that IResourceSettings#getDisableGZipCompression() is also unused. In other words, gzipping of resources is not implemented in Wicket 1.5. Are there plans to do so? Part of me thinks that maybe this feature should be dropped, as compression makes more sense to handle at the servlet container or web server layer (e.g. mod_deflate). Thoughts? -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Fate of CompressedResourceReference in Wicket 1.5?
Hi, CompressedResourceReference in trunk is basically empty and has the comment TODO NG. A quick search through the source leads me to believe that IResourceSettings#getDisableGZipCompression() is also unused. In other words, gzipping of resources is not implemented in Wicket 1.5. Are there plans to do so? Part of me thinks that maybe this feature should be dropped, as compression makes more sense to handle at the servlet container or web server layer (e.g. mod_deflate). Thoughts? -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: body tag contributions with wicket 1.5 (Dojo needs it)
On Mar 3, 2011, at 2:15 AM, Gonzalo Aguilar Delgado wrote: It does not work as I cannot override add method from webmarkupcontainer. Are you sure? In Wicket 1.5-rc2 and well as in trunk, MarkupContainer#add(Component...) is not final. To clarify: in order to mimic the transparent resolver feature, you need to override add(Component...) on BasePage, not on the body WebMarkupContainer. Even if it works I will have to add something to the htlm. Right? Right. You will need this in your HTML: body wicket:id=body If you decide to take Martin's IMarkupFilter approach can you post your share your solution with the list? I am curious to try this as well, as overriding add(Component...) is a bit of hack. -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: body tag contributions with wicket 1.5 (Dojo needs it)
Since isTransparentResolver() is going away in 1.5, the trick that I found is
to create a normal WebMarkupContainer for the body element, then override
add(Component...) of the page to mimic the transparent resolver feature.
Your pages can then contribute to the body element by adding
AttributeModifier, etc. to the WebMarkupContainer.
See:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html#MigrationtoWicket1.5-MarkupContainer.isTransparentResolver%2528%2529removed
Here's an example:
public abstract class BasePage extends WebPage
{
private WebMarkupContainer _body;
public BasePage(PageParameters params)
{
super(params);
// Allow subclasses to register CSS classes on the body tag
WebMarkupContainer body = new WebMarkupContainer(body);
body.setOutputMarkupId(true);
add(body);
// From now on add() will add to _body instead of page
this._body = body;
}
/**
* Return a component that represents the {@code body} of the page.
* Use this to add CSS classes or set the markup ID for styling purposes.
*/
public WebMarkupContainer getBody()
{
return _body;
}
/**
* When subclasses of BasePage add components to the page, in reality
* they need to be added as children of the {@code body} container.
* This implementation ensures the page hierarchy is correctly enforced.
*
* @return {@code this} to allow chaining
*/
@Override
public BasePage add(Component... childs)
{
for(Component c : childs)
{
// Wicket automatically translates head into an
// HtmlHeaderContainer and adds it to the page. Make sure this
// is registered as a direct child of the page itself, not the
// body.
if(null == _body || c instanceof HtmlHeaderContainer)
{
super.add(c);
}
// Everything else goes into the body.
else
{
_body.add(c);
}
}
return this;
}
}
--
Matt
On Mar 2, 2011, at 11:35 AM, Gonzalo Aguilar Delgado wrote:
Hello,
I'm building a wiJQuery equivalent for Dojo. And it seems to work nice
with new wicket 1.5. HeaderContributions are really nice... Great work!
But I ran into problems when trying to setup the themes.
I have to put something like this in the body:
body class=claro
/body
But I rode a lot and discovered that wicket no longer supports
contributing to body because onLoad handler as well others.
Reading in forums I found the BodyTagAttributeModifier but you need a
panel that I wont have.
And the:
body wicket:id=body
add(new WebMarkupContainer(body){
@Override
public boolean isTransparentResolver() {
return true;
}
@Override
protected void onComponentTag(ComponentTag tag) {
tag.put(class, somestyle);
}
});
It will not work because wicket:id attribute removed from body in version 1.5.
So... What's they way to go?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
How to compile a component for both Wicket 1.3 and 1.4?
Hello, I am writing a Wicket component that I would like to use in two different Wicket applications. One application is using Wicket 1.4.3, and the other is a legacy application using Wicket 1.3.6. Unfortunately upgrading this legacy app to 1.4 is not an option. I'm using maven for my build process. Right now I am considering the following approach: 1. Set up a multi-module maven project. 2. Create a common module that contains all the code that will safely execute in both Wicket 1.3 and Wicket 1.4. 3. Create a wicket13 module that contains the 1.3-specific code. 4. Create a wicket14 module that contains the 1.4-specific code. That sounds like a lot of trouble. Can anyone think of a simpler solution, perhaps using maven build profiles? Or am I approaching this completely wrong? -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
