Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
Sorry, didn't mean to sound dismissive. It's a valid point, just I'm
not seeing that anybody could get to anything otherwise unavailable.
On Mon, 25 May 2020 21:02:08 +0200
Carl-Eric Menzel wrote:
> I think the point of this version decoration is not to ensure a
> particular version is requested, because typically only one version of
> a file is available in the application.
>
> The point is instead to defeat any caching, both in the browser and by
> proxies, which might serve the user an outdated version. So I don't
> think there needs to be any checking of that string.
>
> Or is there an actual security impact that I'm missing?
>
> Carl-Eric
>
> On Mon, 25 May 2020 20:47:36 +0200
> Daniel Stoch wrote:
>
> > Hi,
> >
> > Each resource in Wicket is decorated using a version string in a
> > file name by default. It is implemented in
> > FilenameWithVersionResourceCachingStrategy. Depending on DEVELOPMENT
> > or DEPLOYMENT mode it looks like:
> > jquery-ver-1590158412000.css
> > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C.css
> >
> > There is a small security issue, that this strategy does not check
> > if this version is correctly calculated for specific resource and
> > accepts any string as a version identifier, eg.:
> > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_old.css
> > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_bakup.css
> > jquery-ver-XYZABCDEF.css
> > etc.
> >
> > Maybe we should add a check if version passed in request is correct?
> > There is partially such check done in decorateResponse() method. So
> > maybe it is enough to add else block here and raise some exception?
> >
> > @Override
> > public void decorateResponse(AbstractResource.ResourceResponse
> > response, IStaticCacheableResource resource) {
> > String requestedVersion =
> > RequestCycle.get().getMetaData(URL_VERSION); String
> > calculatedVersion = this.resourceVersion.getVersion(resource); if
> > (calculatedVersion != null &&
> > calculatedVersion.equals(requestedVersion))
> > { response.setCacheDurationToMaximum();
> > response.setCacheScope(WebResponse.CacheScope.PUBLIC); } }
> >
> > --
> > Best regards,
> > Daniel Stoch
> >
> > -
> > 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
>
000
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
I think the point of this version decoration is not to ensure a
particular version is requested, because typically only one version of
a file is available in the application.
The point is instead to defeat any caching, both in the browser and by
proxies, which might serve the user an outdated version. So I don't
think there needs to be any checking of that string.
Or is there an actual security impact that I'm missing?
Carl-Eric
On Mon, 25 May 2020 20:47:36 +0200
Daniel Stoch wrote:
> Hi,
>
> Each resource in Wicket is decorated using a version string in a file
> name by default. It is implemented in
> FilenameWithVersionResourceCachingStrategy. Depending on DEVELOPMENT
> or DEPLOYMENT mode it looks like:
> jquery-ver-1590158412000.css
> jquery-ver-F334A4E46CB37347CAB42E2B1A45897C.css
>
> There is a small security issue, that this strategy does not check if
> this version is correctly calculated for specific resource and accepts
> any string as a version identifier, eg.:
> jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_old.css
> jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_bakup.css
> jquery-ver-XYZABCDEF.css
> etc.
>
> Maybe we should add a check if version passed in request is correct?
> There is partially such check done in decorateResponse() method. So
> maybe it is enough to add else block here and raise some exception?
>
> @Override
> public void decorateResponse(AbstractResource.ResourceResponse
> response, IStaticCacheableResource resource) {
> String requestedVersion =
> RequestCycle.get().getMetaData(URL_VERSION); String calculatedVersion
> = this.resourceVersion.getVersion(resource); if (calculatedVersion !=
> null && calculatedVersion.equals(requestedVersion))
> { response.setCacheDurationToMaximum();
> response.setCacheScope(WebResponse.CacheScope.PUBLIC); }
> }
>
> --
> Best regards,
> Daniel Stoch
>
> -
> 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: ListView Add/Remove via AJAX...
Hi James,
Some time ago I wrote this:
https://github.com/duesenklipper/wicket-appendablerepeater
It should work with forms. If not, let me know.
Best regards
Carl-Eric
On 27.03.2018 14:42, James Carman wrote:
It has been a while since I've used Wicket and man, I really forgot how
much I love this framework! It may be that I'm rusty, but I've searched
quite a bit and tried all the suggestions I've found, but I can't seem to
make add/remove via AJAX work for a ListView while preserving the input
data. I am using Wicket 8.0.0-M9. Here's what I've done so far:
correctChoiceGroup = new CheckGroup<>("correctChoices",
Model.ofSet(Sets.newHashSet()));
correctChoiceGroup.setRequired(true);
correctChoiceGroup.setOutputMarkupId(true);
correctChoiceGroup.setRenderBodyOnly(false);
final IModel choicesModel = Model.ofList(new LinkedList<>());
choicesView = new ListView("choices", choicesModel) {
@Override
protected void populateItem(ListItem item) {
final int index = item.getIndex();
item.add(new TextField<>("field", item.getModel()));
item.add(new Check<>("check", Model.of(index)));
final AjaxSubmitLink deleteLink = new AjaxSubmitLink("deleteButton") {
@Override
@SuppressWarnings("unchecked")
protected void onSubmit(AjaxRequestTarget target) {
final ListView listView = findParent(ListView.class);
listView.getModelObject().remove(index);
listView.removeAll();
target.add(correctChoiceGroup);
}
};
deleteLink.setDefaultFormProcessing(false);
item.add(deleteLink);
}
}.setReuseItems(true);
correctChoiceGroup.add(choicesView);
add(new AjaxSubmitLink("addButton") {
@Override
protected void onSubmit(AjaxRequestTarget target) {
choicesView.getModelObject().add("");
choicesView.removeAll();
target.add(correctChoiceGroup);
}
}.setDefaultFormProcessing(false));
add(correctChoiceGroup);
When I click on the delete link (I have a similarly-implemented "add" link
outside of the ListView), all of the input data goes away, since I am
losing the original items from the removeAll() call. Now, I am doing the
removeAll() to force Wicket to realize that I've changed the underlying
list, otherwise, the original items are reused and the it always looks like
the last item is removed. I'm sure I'm just rusty, but I am banging my
head on this one.
Thanks,
James
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Download byte array
You can use a org.apache.wicket.request.resource.ByteArrayResource instead - It's an IResource implementation that takes a byte array. You can then use the resource in a DownloadLink, for example. Carl-Eric On Mon, 14 Apr 2014 12:11:06 +0200 christoph.ma...@t-systems.com wrote: Hello, Iam using a FileResourceStream to download a file. This needs an File, which I create on the fly like this: tempFile = File.createTempFile(SLA, .xls); InputStream data = new ByteArrayInputStream(ConsoleDataHandlerImpl.getInstance().getReportAsByteStream(beginDate,endDate)); Files.writeTo(tempFile, data); It works fine. But the problem is that it save the tempfile in my tmp folder. Is there a RessourceStream in Wicket which can handle a byte array so that I don't need a tempfile? Mit freundlichen Grüßen Christoph Manig - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Show Excelsheet in Browser
If the browser doesn't know how to display an excel file inline, it will still open a download window. This has nothing to do really with Wicket - if you want the browser to display an actual Excel .xls file, you need a browser plugin that can do it. What you can do, for example, is parse the file on the server and generate a HTML table to show in the browser (or display it in any other way). Carl-Eric On Mon, 24 Mar 2014 15:45:24 +0200 Martin Grigorov mgrigo...@apache.org wrote: Yes, DownloadLink uses ContentDisposition.ATTACHMENT. You need #INLINE. That's why I said to use it as an example. Martin Grigorov Wicket Training and Consulting On Mon, Mar 24, 2014 at 3:39 PM, christoph.ma...@t-systems.com wrote: The DownloadLink open the save as dialog but I want to show the data in a browser embedded excel. Are there other Wicket-Components to implement this? Mit freundlichen Grüßen Christoph Manig Systems Engineer T-Systems International GmbH Systems Integration - SC Travel, Transport Logistics Hoyerswerdaer Str. 18 01099 Dresden tel.: +49 (0) 351 / 8152 - 188 fax:+49 (0) 351 / 8152 – 209 email: christoph.ma...@t-systems.com T-SYSTEMS INTERNATIONAL GMBH Aufsichtsrat: Thomas Dannenfeldt (Vorsitzender) Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan, Thilo Kusch, Dr. Markus Müller, Georg Pepping, Hagen Rickmann Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE50335567 -Ursprüngliche Nachricht- Von: Martin Grigorov [mailto:mgrigo...@apache.org] Gesendet: Montag, 24. März 2014 14:25 An: users@wicket.apache.org Betreff: Re: Show Excelsheet in Browser then all you need is to set few response headers: Content-Disposition: Inline Content-type: (see http://stackoverflow.com/a/2938188/497381) See org.apache.wicket.markup.html.link.DownloadLink#onClick for an example how to do this Martin Grigorov Wicket Training and Consulting On Mon, Mar 24, 2014 at 3:17 PM, christoph.ma...@t-systems.com wrote: Hello, iam getting an byte array from the backend and I want to send this to the browser with an outputstream. So the browser notice that he gets an excel sheet and shows this. It should be the same if you open pdfs with the browser while downloading this data. Mit freundlichen Grüßen Christoph Manig -Ursprüngliche Nachricht- Von: Martin Grigorov [mailto:mgrigo...@apache.org] Gesendet: Montag, 24. März 2014 14:03 An: users@wicket.apache.org Betreff: Re: Show Excelsheet in Browser Hi, You can use a JavaScript solution like http://handsontable.com/index.htmlto show spreadsheet like tables. I am not sure whether it supports multiple sheets. I guess there are more such JS solutions out there. Martin Grigorov Wicket Training and Consulting On Mon, Mar 24, 2014 at 2:56 PM, christoph.ma...@t-systems.com wrote: Hello, I want to show an excel data set by clicking on a wicket button. The sheet should be shown in the browser and this data set has multiple table-sheets. How can I do that with wicket? Mit freundlichen Grüßen Christoph Manig - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Focus navigation on form components by pressing ENTER
You don't need an ajax behavior to do this. This is all client-side
javascript only, as described in the stackoverflow post.
You can of course use a regular behavior to emit the necessary
javascript.
Carl-Eric
On Sat, 7 Sep 2013 15:50:06 +0500
Farrukhjon SATTOROV (farrukh) fireda...@gmail.com wrote:
My code here:
sizeTextField.add(new
AjaxEventBehavior(ENETER_KEY_OR_SOMTHING_LIKE_THIS) {
@Override
protected void onEvent(AjaxRequestTarget target) {
target.focusComponent(unitTextField);
}
});
but i don't known how handler passing ENTER key and pass this as
parameter to AjaxEventBehavior.
On Sat, Sep 7, 2013 at 3:36 PM, Sven Meier s...@meiers.net wrote:
http://stackoverflow.com/**questions/4494552/change-**
enter-from-submission-to-tab/**4494691#4494691http://stackoverflow.com/questions/4494552/change-enter-from-submission-to-tab/4494691#4494691
On 09/07/2013 12:11 PM, Farrukhjon SATTOROV (farrukh) wrote:
Hi everyone, how to set focus on next form component (TextField) by
pressing on ENTER key in current TextField. Thanks in advance.
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@wicket.**apache.orgusers-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: Wicket serialization concerns
On Tue, 20 Aug 2013 23:01:29 + Michael Chandler michael.chand...@onassignment.com wrote: I'm led to believe that creating a reference to any of my domain classes within a Wicket component (as a field or in a method implementation) will expose me to a serialization error unless I put it in a Wicket model. Am I correct about this? Basically yes. Any non-transient field in your Component will be serialized. That includes final local variables or final method/constructor parameters if you reference those from within an inner class. That will make the compiler generate a hidden field to keep that reference for the inner class. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: No page id appended to some stateful pages
On Wed, 07 Aug 2013 13:48:38 -0400 Bertrand Guay-Paquet ber...@step.polymtl.ca wrote: The problem I see is that AbstractRepeater's onPopulate() is called during onBeforeRender() and this is not done when the stateless status of the page is first checked. Therefore, no pageId is added unless other components not located inside repeaters are also stateful. Should I create a JIRA issue for this? I haven't analyzed this myself yet, but I have run into a similar problem recently. If you could open an issue (possibly with a quickstart?), that would be great. Thanks Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: shared models - rules
On Fri, 22 Feb 2013 12:42:14 -0800 (PST) grazia grazia.russolass...@gmail.com wrote: Say I have a page with several components all sharing the same model; what are the rules of thumb to make sure the same model gets updated byt the different components on the page ? If you only ever pass these components that one model, then they only have that one to update, so that's what they'll do. Are you seeing some sort of unexpected effect? Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: shared models - rules
On Fri, 22 Feb 2013 13:23:20 -0800 (PST) grazia grazia.russolass...@gmail.com wrote: If the form contains a panel, and that panels contains a textfield, and all share the same IModelMyClass, this is what I see: the textField model gets updated, but not the panel's model and not the form's model. It seems I am missing something with the panels ... it is as if they were some sort of barrier ... Can you show us some code? The textfield presumably should be working on an IModelString - what are the other models? Try pasting your form, panel and textfield code somewhere so we can have a look. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: shared models - rules
form.add(new Button(appointButton) {
public void onSubmit() {
System.out.println(HERE = + getModelObject() );
-- whatever it is the choice in the autocomplete which is within
the MyPersonnelPanel this is always null
}
I didn't look at the rest of the code yet since it's pretty late here,
but this definitely won't work. You're calling the Button's
getModelObject(), not the Form's, since at this point you're in the
Button's onSubmit(), so this would be the Button. You don't give the
button a model, so you're getting null. If you want to use it in there,
you can for example call form.getModelObject().
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Migration issue: page that writes binary data to the response
On Tue, 19 Feb 2013 09:23:28 +0100 Martin Dietze d...@fh-wedel.de wrote: IMO the problem is not that much how the response is generated, but how the component is already uses within the system. At this point creating a download link is simple as it simply is a BookmarkableLink to that page with the appropriate page parameters. Consequently, the download links are bookmarkable. You can mount shared resources just like you can mount pages, so they can still be bookmarkable. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Migration issue: page that writes binary data to the response
I would simply do this in a Resource (e.g. subclass AbstractResource)
rather than in a page. Resources are for binary data, Pages are for
markup. That way you don't have to mess around in any way with the
response or anything like that.
Is there a particular reason you're using a page?
Carl-Eric
On Mon, 18 Feb 2013 17:55:37 +0100
Martin Dietze d...@fh-wedel.de wrote:
In the project I'm currently porting from 1.4.x to 6.6.0 I've
run into an issue with Wicket pages which stream binary data
into the WebResponse (e.g. ZIP archives created on the fly).
First thing I found was that obviously I *have* to create
templates for these pages even though they are not going to be
used for anything.
The second thing is more serious: when writing to the response I
get an IllegalStateException as the template code has already
been written to it. This can be circumvented by calling
Response.reset() before Response.write() in my code. However in
development mode I still get an ISE as in Page.onAfterRender()
there's this code here:
| if
(getApplication().getDebugSettings().isOutputMarkupContainerClassName())
| { | String className = Classes.name(getClass());
| getResponse().write(!-- Page Class );
| getResponse().write(className);
| getResponse().write( END --\n);
| }
}
Now of course I can write:
| @Override
| protected void onAfterRender() {
| try { super.onAfterRender(); } catch (IllegalStateException e) { }
| }
... but I guess we agree that while this works it is far from nice.
I am not sure if I understand correctly what the above code is
trying to tell me. Does it mean that I am simply not supposed to
deliver my ZIP files by a Wicket page that way?
If with today's Wicket version there's a different or even better
way to do this, which one would that be?
Else, would there be any harm in making the Page class more
friendly to this kind of use, by e.g. putting the above
if-statement into an overridable method and adding an option to
the Component class to tell it that there's no markup for it and
it should simply not expect any?
Cheers,
M'bert
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Fundamental forms/models issue
On Mon, 18 Feb 2013 17:47:16 + Michael Chandler michael.chand...@onassignment.com wrote: Good morning/afternoon everyone. I'm having a basic problem fully deciphering how to best manage my forms, specifically related to Models that are attached to forms. Since a Wicket WebPage has it's constructor invoked only one time in the application lifecycle, I'm failing to fully understand how to present a form that has a model bound to it without inadvertently sharing that instance of the Model with every user of the application. It seems like a fundamental issue that I'm failing to fully grasp and could use some input. There is the mistake: Page instances are *not* shared. Every user has their own instances. There can be plenty of instances of any page at any given time. Pages get constructed any time *you* do it (by calling new MyPage(...)) or Wicket does it (when the user first gets to a bookmarkable page, Wicket will construct a fresh instance by using either the no-arg constructor or the PageParameters constructor). Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Migration issue: page that writes binary data to the response
On Mon, 18 Feb 2013 19:03:41 +0100
Martin Dietze d...@fh-wedel.de wrote:
On Mon, February 18, 2013, Carl-Eric Menzel wrote:
Is there a particular reason you're using a page?
One - unfortunately - big reason: it's legacy code (most of
which I did not even write myself). The Wicket upgrade is badly
needed for browser compatibiy, however I don't want to change
code if it's not absolutely necessary.
For generating binaries, I would *really* recommend doing this change.
Pages simply are not a good fit for that. Also, it shouldn't be that
big of a change, since you're writing to the Response anyway. Within
AbstractResource's WriteCallback you're going to use the same Response
object, so you can simply copy most of your code over without much
change.
(pseudocode from memory, but close enough)
MyResource extends AbstractResource {
@Override newResourceResponse(Attributes att) {
att.setFilename(foo.pdf);
att.disableCaching();
att.setContentType(text/pdf);
att.setWriteCallback(new WriteCallback() {
@Override writeData(Attributes att) {
Response r = att.getResponse();
// write to the response here like you did before
}
});
}
}
Except in this case you won't have to mangle the Response object like
you have to do with the page.
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Unable to Traverse with IVisitor: Some Class Names Have $1 at the end
Most of the time, the class names are right, but sometimes, I don't
get Wicket org names, I get these:
com.mycompany.MyForm.MyPanel$1 ( -- on a Button!)
com.mycompany.SomeForm$1 ( -- on a Button!)
What's going on here, why can't I get the actual
org.apache.wicket.markup.html.form.Button class names?
That's Java for you. When you create a button like this:
class MyPage {
...
new Button() {
...
}
}
...then you actually create a new class at that spot. It's anonymous,
so it doesn't have a really usable name, but internally, the compiler
and VM use enclosingclassname$someindexvalue to create that name.
Thus, you get MyPage$1 if this is the first anonymous subclass you
create within MyPage.
My usual solution to this is to not just print out the class name, but
first check whether the class name contains a $, and if so, get the
superclass instead.
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: merge all properties file into one file
Is there any way that i can merge all my properties file into one big properties file ? If you application class is MyApplication then you can put everything into MyApplication.properties if you want. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Which github branch
Wicket github has both a 'master' 'trunk'. Which one should I choose? (or is there something else for 'latest 1.6.x code'?) It's currently still in master. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [DISCUSS] Security Frameworks
[X] I use Shiro We use Shiro on our project (using wicketstuff's shiro integration and our own custom Shiro realm implementation). We use it because it gives us a permission-based approach (not just roles-based) and is more easily configured than e.g. SWARM/WASP. I also quite like the hierarchical approach to permissions that Shiro allows. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bug WICKET-4789 still in 6.1.1 ?
Do you have a complete stacktrace?
On Thu, 11 Oct 2012 06:02:33 -0700 (PDT)
nemanjko nemanja.kos...@gmail.com wrote:
I'm not sure that the error I'm getting is related to the WICKET-4789
that was in 6.0,
but it looks like it.
After upgrading from 6.0.0 to 6.1.1, I am getting this error:
java.lang.NullPointerException
org.apache.wicket.protocol.http.servlet.ServletWebResponse.encodeURL(ServletWebResponse.java:181)
I use a piece of code to remove jsessionid from URL for search
engines. The line where it happens is where I use
super.encodeURL(url):
public String encodeURL(CharSequence url) {
final String agent = webRequest.getHeader(User-Agent);
return isAgent(agent) ? url.toString() :
super.encodeURL(url); }
Is it still a bug?
If not, is there some other way to remove jsessionid from URL?
Thanks,
Nemanja
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Bug-WICKET-4789-still-in-6-1-1-tp4652883.html
Sent from the Users forum mailing list archive at Nabble.com.
-
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: HybridUrlCodingStrategy in Wicket 1.5
On Sat, 29 Sep 2012 09:54:27 -0600
Alec Swan alecs...@gmail.com wrote:
mountPage(ms, MyPage.class) generates URLs like /lrm/ms?oid=123
What I would like is URLs like /lrm/ms/oid/123
What's the easiest way to accomplish this?
mountPage(ms/oid/${oid}, MyPage.class);
The ms/oid/ is just the string that will be part of the url, the
${oid} means that whatever is at this point in the path will be
available as a PageParameter with the name oid.
More details in the Javadoc of MountedMapper.
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using a div/span tags for wicket components
On Fri, 21 Sep 2012 14:48:05 + Corbin, James jcor...@iqnavigator.com wrote: input type=text wicket:id=someId …/ I would like to, instead, specify a span or a div in the markup and bind the TextField to that markup instead. Why? A TextField needs to bind to an input tag, because that is what the browser will render as a text field. Of course, you could probably override TextField's onComponentTag to not do the tag type check, if you wanted. Not sure whether that is final (can't check right now). But to be honest, at least right now I'm not seeing what would be gained. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[CVE-2012-3373] Apache Wicket XSS vulnerability via manipulated URL parameter
Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Wicket 1.4.x and 1.5.x Description: https://wicket.apache.org/2012/09/06/cve-2012-3373.html It is possible to inject JavaScript statements into an ajax link by adding an encoded null byte to a URL pointing to a Wicket app. This could be done by sending a legitimate user a manipulated URL and tricking the user into clicking on it. This vulnerability is fixed in - Apache Wicket 1.4.21 https://wicket.apache.org/2012/09/05/wicket-1.4.21-released.html - Apache Wicket 1.5.8 https://wicket.apache.org/2012/08/24/wicket-1.5.8-released.html Apache Wicket 6.0.0 is not affected. Credit: This issue was reported by Thomas Heigl. Apache Wicket Team - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Apache Wicket 1.4.21 is released
This is 21st release of the Wicket 1.4.x series. This is also the last release of the 1.4.x series, rounding up the remaining bugfixes. No further releases will happen in this branch. Git tag: release/wicket-1.4.21 Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12320171 Maven: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4.21/version /dependency Download the full distribution (including source): http://www.apache.org/dyn/closer.cgi/wicket/1.4.21 The Wicke - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: accessing components within a ListView
On Thu, 5 Jul 2012 11:36:06 -0400
Carter, Isaac isaac.car...@mantech.com wrote:
I'm wondering if anyone knows how to properly access components that
exist within a repeating listview? I have two buttons (we'll say an
edit and remove button) that I'm repeat over and add them to the
listview. I need to be able to disable all of the edit buttons that
exist within a listView at a given moment in time when another
property is being edited. Does anyone know how to access all of the
other edit buttons that exist at a given time in the listview?
I'd do it the other way around: Instead of actively looking for the
buttons and *setting* the visibility, override onConfigure() in the
buttons and have them set their own enabled state depending on whatever
it is you need to check:
...
listItem.add(new Button(...) {
public void onConfigure() {
super.onConfigure();
this.setEnabled(!myObject.isEditing());
}
}
...
[untested pseudocode]
Hope this helps
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: interesting issues with Wicket and Javassist
On Fri, 22 Jun 2012 11:36:51 -0400 Andrew Geery andrew.ge...@gmail.com wrote: My question is: should Wicket have realized that the proxy'ed Person object was actually a Person class and called the appropriate converter? Looking at this -- http://stackoverflow.com/questions/1139611/loading-javassist-ed-hibernate-entity -- it looks like there is not a generic way of handling this, without explicitly checking for something like a HibernateProxy. Perhaps the answer is simply: make sure that proxies don't end up in the UI layer? That would certainly be the cleanest solution. Otherwise the converter lookup mechanism would have to be adjusted. That might be a rather expensive operation - it's a simple map lookup right now so it's very fast but doesn't work with subclasses. Long ago I wrote my own string conversion classes for an application I was working on. It used a chain-of-responsibility pattern, where a number of converters would try converting the value one after another until one succeeded. It worked well and it could probably be adapted. Two things make me wary of this approach though: - it'd be a major API break - we'd have to look at performance very closely. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Verifying image HREF with Wicket tester
On Tue, 19 Jun 2012 15:21:17 -0600 Alec Swan alecs...@gmail.com wrote: I had to make sure that my img element had a closing /img The problem is that org.apache.wicket.util.tester.TagTester#createTagByAttribute requires the img element to be closed, i.e. img/ or img/img. Otherwise closeTag variable is never set and the loop does not exit. Seems like a bug to me, isn't it? A lone open img tag wouldn't be valid XHTML. Does our HTML5 support include support for non-wellformed documents? Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Verifying image HREF with Wicket tester
In this case, yes, I think. Carl-Eric On Wed, 20 Jun 2012 09:27:27 -0600 Alec Swan alecs...@gmail.com wrote: So, this is a bug, right? On Wed, Jun 20, 2012 at 2:36 AM, Martin Grigorov mgrigo...@apache.org wrote: On Wed, Jun 20, 2012 at 11:34 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Tue, 19 Jun 2012 15:21:17 -0600 Alec Swan alecs...@gmail.com wrote: I had to make sure that my img element had a closing /img The problem is that org.apache.wicket.util.tester.TagTester#createTagByAttribute requires the img element to be closed, i.e. img/ or img/img. Otherwise closeTag variable is never set and the loop does not exit. Seems like a bug to me, isn't it? A lone open img tag wouldn't be valid XHTML. Does our HTML5 support include support for non-wellformed documents? Yes. Carl-Eric - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Models and Session Size
On Tue, 19 Jun 2012 14:01:13 -0500 Douglas Ferguson the...@gmail.com wrote: I was intrigued by the comment that more extensive use of Model would reduce session size. Why would this be? Won't models still wind up in the data graph for the Page and thus be in the pagemap? Well, apart from the fact that you should pretty much always be passing Models around in your Wicket layer rather than bare objects, I'm almost sure that article refers to LoadableDetachableModels. Those drop all references at the end of the request, except for something like a database key. In the next request, the required data is loaded again on the fly. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket not able to find component after adding container componenent
You need to add the container to the panel:
add(postDomainContainer);
And you need to add the form to the container instead of the panel
itself:
postDomainContainer.add(commentForm);
Your component hierarchy must match the tag hierarchy.
Hope this helps
Carl-Eric
www.wicketbuch.de
On Sun, 20 May 2012 03:40:51 -0700 (PDT)
kshitiz k.agarw...@gmail.com wrote:
Hi,
I am trying to cover a form in a container.
*SubmitCommentPanel:*
wicket:panel
* div wicket:id=submitCommentPostDomainContainer*
form
wicket:id=commentForm /form
/div
/wicket:panel
The java code is :
public SubmitCommentPanel(String id, final ListItemPostDomain
listItem, final UserDomain userDomain) {
super(id);
// defining container for refreshing list of posts
final WebMarkupContainer postDomainContainer = new
WebMarkupContainer( submitCommentPostDomainContainer);
postDomainContainer.setOutputMarkupId(true);
FormCommentDomain commentForm = new
FormCommentDomain( commentForm,
new
CompoundPropertyModelCommentDomain(commentDomain));
};
* add(commentForm);*
But the error is:
*Last cause: Unable to find component with id 'commentForm' in
[WebMarkupContainer [Component id =
submitCommentPostDomainContainer]]*
But if I remove container portion, the code runs fine. Cant I add the
container. One thing to note that the whole panel is in another
container:
div wicket:id=postDomainListContainer
form wicket:id=postForm
/form
* div
wicket:id=submitCommentPanel/div br/br*
/div
The above panel though runs fine. What is the issue?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/wicket-not-able-to-find-component-after-adding-container-componenent-tp4646756.html
Sent from the Users forum mailing list archive at Nabble.com.
-
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: Passing parameter to a portion of a page
On Mon, 30 Apr 2012 10:05:46 -0700 (PDT) kshitiz k.agarw...@gmail.com wrote: Thanks for the reply Dan...now consider a situation: You have 5 drop downs, each with onselectionchange enabled. When you change the choice of any one drop down, the chosen value should be passed as parameter to that drop down only, so that it will display new value. Rest drop downs should not get changed. How will you do that? I very much recommend looking at wicket-examples, they show very well how Wicket components and pages work together. For most usecases, your components will not have to look directly at page parameters *at all*, and certainly not at other components' parameters. On way would be to allocate each drop down a unique id and then, associate each parameter being passed to the same page with that id. This will help to judge the coming parameter belongs to which drop down. But is there any more efficient way? Your components need a unique id in Wicket anyway. You don't have to handle those parameters yourself though. Simply override DropDownChoice#wantOnSelectionChangedNotifications() to return true, and then #onSelectionChanged will be called *for this component only* when a new value is selected. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ListView (or other Repeater) with backing map
On Mon, 30 Apr 2012 10:25:21 -0700 (PDT) cmagnollay cmagnol...@gmail.com wrote: So essentially I want to use Wicket 1.5 to display an item and its associated quantity. The data structure I am using to back this is a Map (new HashMap()) where Item is a POJ whose details are of no consequence. Essentially I would like to use one of wicket's repeaters, but I only have experience using ListView. Is there a repeater that would work well with a Map, or am I going to need to code my own? If I need to code my own, what is the best class to override? The List has has key-value pairs of type: Item-Integer where integer is the quantity. I'd just use Map#entrySet, which gives you a SetMap.EntryItem,Integer. You can turn that into a list and feed it to a ListViewMap.EntryItem,Integer. That way you have an Entry in each ListItem and can simply use its two parts. Hope this helps. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ListView (or other Repeater) with backing map
On Mon, 30 Apr 2012 10:43:30 -0700 (PDT)
cmagnollay cmagnol...@gmail.com wrote:
if the map is called something like
MapItem, Integer itemMap = new HashMapItem, Integer();
Hmm, so I would instantiate the ListView like so?
[...]
Is this what you are implying somewhat? Thanks for the answer by the
way, I had not considered just, for lack of a better term, fooling
the listview into using my map elements.
Basically yes, though the propertymodel won't work like that. I'd do
something like this (pseudocode):
MapItem,Integer itemMap = ...;
IModelListMap.EntryItem,Integer mapListModel = new
LoadableDetachableModel() {
load() {
return new ArrayList...(itemMap.entrySet());
}
};
...new ListViewMap.Entry...(id, mapListModel) {
populateItem(ListItemItem,Integer li) {
...
}
}
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: ListView (or other Repeater) with backing map
On Mon, 30 Apr 2012 11:38:36 -0700 Dan Retzlaff dretzl...@gmail.com wrote: You can call LDM#detach() after the modification, but since this particular implementation is so light, I'd just use AbstractReadyOnlyModel instead. It doesn't cache, so detach is not required. Actually, getObject() can be called pretty often, so that would incur the cost of creating the new List object *each time*. I would really use the LDM. Since in my example the LDM is passed directly into the ListView as its default model, the ListView will take care of detaching [1]. cmagnollay, that means that on each render you should simply see whatever is currently in your map, so it should be up to date on its own without further action. An LDM calls the load() method the first time its getObject() is called. The value you return from load() will be cached until detach() is called on the LDM. The normal usecase is to do an expensive operation (load from DB, create a lot of objects, etc) only once in a request but to still have fresh data in each request. Also it reduces session size because the cached data is not kept between requests. Hope this helps! Carl-Eric [1] Carl-Eric's rule of detaching models: *always* do one of the following: - detach the model yourself - pass the model to one of your child components or your superclass, thus making it that code's responsibility. You never know what model implementation you might be getting as a parameter. Be nice to whoever calls you. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ListView (or other Repeater) with backing map
On Mon, 30 Apr 2012 12:15:20 -0700 Dan Retzlaff dretzl...@gmail.com wrote: I assumed the action phase would dereference the ListItemModel (e.g. to remove it from the map), hence dereference the LDM, and then require the explicit detach() before rendering. Agreed that LDM is the way to go if you're concerned about the ArrayList constructions. That assumption depends very much on the code you give the model to. Many places will simply call getObject() instead of keeping a reference to whatever is inside. PropertyModel is one of them that is very commonly used. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: a model for passing data between pages
On Mon, 9 Apr 2012 07:24:34 -0700 (PDT)
armhold armh...@gmail.com wrote:
I'm thinking of storing the DTO in the user's session as a detached
entity, and using a model like the following on the various pages:
That is perfectly valid approach, and one that we've been using for
some usecases. However, instead of this:
return (T) Session.get().getAttribute(key);
I'd rather use a custom Session subclass with typesafe getters and
setters:
class MySession extends WebSession {
private MyDTO dtoForFlow;
public MyDTO getDtoForFlow() {
return dtoForFlow;
}
// ...setter too...
public static MySession get() {
return (MySession) Session.get();
}
}
Alternatively you might want to look at the wicket-seam integration and
use Seam conversations.
Carl-Eric
www.wicketbuch.de
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: a model for passing data between pages
On Mon, 9 Apr 2012 16:23:38 -0700 (PDT) armhold armh...@gmail.com wrote: SessionModelMyDTO model = new SessionModelMyDTO(MyDTO.KEY, new MyDTO()); Not typesafe, as you pointed out, but fairly concise. If you have a lot of different types where you use that, this map-like approach is probably better, yes. Alternatively you might want to look at the wicket-seam integration and use Seam conversations. Actually we started out using Wicket-CDI + Seam, expressly because of the conversation support, but ran into issues making it work on WebSphere... a topic for another day. :-) Heh. WebSphere, a fountain of constant joy :-) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Injection in a Resource
On Tue, 7 Feb 2012 16:08:37 +0100 Gaetan Zoritchak g.zoritc...@moncoachfinance.com wrote: Hi all, I use guice in my applications. I need to inject some code (service) in a DynamicImageResource. It is not straightforward because a Resource is not a component. Does anybody has already done that? What would be the best way? You can call the Injector directly in your constructor: Injector.get().inject(this); The effect is the same as in Components: It will inject all your annotated fields. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5 with Shiro for security ...
There's a shiro integration project in wicketstuff-core. We use it and it works well. Carl-Eric www.wicketbuch.de On Thu, 15 Dec 2011 08:56:25 -0800 (PST) armandoxxx armando@dropchop.com wrote: Got a little question. I'm wrapping Apache Shiro as security framework for my application. And I use wicket-auth-roles for wrapping shiro login, logout, get roles and stuff methods. I've got a question for isSignedIn() method which is final. I can't override it to ask shiro if user is logged in or not. Any workaround for this? I really don't want to implement all Authentication/Authorization logic on my own, since wicket already implements this. Kind regards Armando -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-with-Shiro-for-security-tp4200743p4200743.html Sent from the Users forum mailing list archive at Nabble.com. - 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: Problem with check / uncheck all using CheckGroupSelector
On Fri, 18 Nov 2011 07:31:48 -0800 (PST) massizigao fha...@online.de wrote: Hello, i am implementing a dataview table with a checkbox column. At the top of the column i place a checkbox to select/unselect all rows. But It is not working as i want. Using the class Check: checking and unchecking all rows works, but the collection to hold the selected rows is not getting populated. Using the classes CheckBox and AjaxCheckBox: checking and unschecking does not work, but the collection is getting populated. Sorry for eventual duplication, but i search this forum and the web and i couldn't get a hint to fix this problem. I will highly appreciate your help. Here are some code snippet that could help: You need to use the appropriate combination of checkbox, group and selector. 1) If you use a CheckGroup, then you have to build your checkboxes with Check instances, and they need to be children of the CheckGroup. In your example, add your dataview to the CheckGroup, so the Check instances are also underneath that. Then you can use CheckGroupSelector. 2) You can also use CheckBox instances - these don't need to be grouped together, they are just all separate boolean checkboxes. To select/unselect all of these you need to use CheckBoxSelector. 3) You can also use a CheckboxMultipleChoice together with CheckboxMultipleChoiceSelector. For your case I recommend option 1, since you are using listview. I hope this helps. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5.1 image resource not available if parent component is disabled
On Tue, 4 Oct 2011 10:41:27 +0200 Martin Grigorov mgrigo...@apache.org wrote: RequestListenerInterface stops the execution of callbacks for disabled and/or invisible components/behaviors but its seems it also forbids requesting a resource ... I think this is a not-so-easy problem, actually. In this use case (render an image) it seems obvious that even though the whole panel is disabled, it is being rendered, so the image resource should work. But is it always true that a resource should be allowed even if the parent is disabled? On the other hand, this can only affect component-hosted resources, I think. One could reasonably say that in those cases the component is responsible to see whether to allow the resource. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5.1 image resource not available if parent component is disabled
On Tue, 4 Oct 2011 10:59:53 +0200 Martin Grigorov mgrigo...@apache.org wrote: I think this is a not-so-easy problem, actually. In this use case (render an image) it seems obvious that even though the whole panel is disabled, it is being rendered, so the image resource should work. Define disabled image and we may find a solution :-) Well, you can have for example a form that is disabled, so the user can't input anything. However, within that form you have an image, possibly one that's generated on the fly. Should that image be shown? - no = Then a disabled form can't have any non-context images at all. Not good. - yes = Then a possibly costly image generation might run even though the form around it is disabled. Good/bad? Depends on the application. - depends = For resources we should probably check isEnabled rather than isEnabledInHierarchy and make the component responsible for checking its own isEnabledInHierarchy. What do you think? Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Authentication and sessions - the right way?
On Mon, 3 Oct 2011 00:54:31 -0700 (PDT) Zeldor pgronkiew...@gmail.com wrote: It all works fine on my computer, but when I deploy it, it stops working. Session gets detached on the way and I cannot fetche the data to my models. Yes, I keep user data in my session, I could do it with datastore queries, but session is better solution on AppEngine. And problem would still be the same pretty much. There are 2 problems, which I don't really understand: Can you show the relevant code? Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Authentication and sessions - the right way?
On Mon, 3 Oct 2011 00:54:31 -0700 (PDT) Zeldor pgronkiew...@gmail.com wrote: 2. How to fetch data from Guice in Session? I have a RepositoryUser Inject, but when it is used in Session it throws nullpointer exception. Should I have it in session at all? I guess repopulating user data like that is not the best idea, I should probably just redirect him to login page again, if session somehow losses data. Only components get automatic injection - to have the injection work in session, put this in your Session constructor: InjectorHolder.getInjector().inject(this); Or for 1.5: Injector.get().inject(this); Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Authentication and sessions - the right way?
On Mon, 3 Oct 2011 01:10:58 -0700 (PDT) Zeldor pgronkiew...@gmail.com wrote: But would it be possible to store User data in the session without having to fetch it from datastore on every request? My users don't interact with each other and they operate only on their own data. So it'd be most efficient to store User data in the session and interact with db only when some data is changed. Yes, just put a field in your Session and add getter/setter. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Authentication and sessions - the right way?
On Mon, 3 Oct 2011 10:31:38 +0200 Martin Grigorov mgrigo...@apache.org wrote: Yes, just put a field in your Session and add getter/setter. This is not good. This is error prone. This way you'll have to keep the instance in the Session in sync with the data DB. Additionally the memory size will increase for no reason. Select by primary key (user id) is fast operation. That depends on what you're doing. One possibility is that it's mostly read-only data, then it can be a speed boost to just keep that stuff in the session. Of course, if you have writes all over the place, then that could become messy. An alternative could be a model implementation that reads from the session and updates both session and DB on a write. That would basically be a cache then. Selecting by user id is *probably* fast, but it depends on what other data needs to be joined to it. It might also be a more costly operation. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: getImageData() of Image not called on component instantiation in IE
Do you have a quickstart to try this?
Carl-Eric
www.wicketbuch.de
On Thu, 8 Sep 2011 13:37:03 -
martin.ase...@mail.bg wrote:
Would anyone help me with this? I'm desparate on fixing it
Thank you,
Martin
- Цитат от martin.ase...@mail.bg, на 06.09.2011 в 15:51 -
Hello,
I have the following problem. I have a repeater which declares Images
as so:
NonCachingImage image1 = new NonCachingImage(image1, new
BufferedDynamicImageResource() {
private static final long serialVersionUID = 1L;
@Override
protected byte[] getImageData() {
return detachable.getObject().getItem1().getThumbData();
}
});
When the repeater is rendered and displayed in IE, getImageData is not
called and therefore images are not shown. However, if I copy the
image src
and hit that URL, the image gets loaded.
I believe for some reason IE thinks the image is cached, although it
has never beed loaded and therefore does not retrieve the source of
the image. Don't know if this is the real reason.
Has anybody been into this issue before?
Regards,
Martin
-
Сега е по-лесно да получиш най-добрата
куриерска услуга на
телефон *3456(*DHL6)
-
Mail.bg: Безплатен e-mail адрес. Най-добрите характеристики на
българския пазар - 10 GB пощенска кутия, 20 MB прикрепен файл,
безплатен POP3, мобилна версия, SMS известяване и други.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket releases Wicket 1.5
On Thu, 8 Sep 2011 00:17:25 +0200 Martijn Dashorst dasho...@apache.org wrote: The Apache Wicket team is proud to announce the immediate availability of the newest release of their component oriented open source Java web framework. Apache Wicket 1.5 has been in development for the last two years and brings many improvements over previous versions. Congratulations! And thanks to the Wicket team for the good work. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
On Wed, 27 Jul 2011 18:29:22 -0400 Jeremy Thomerson jer...@wickettraining.com wrote: Hello all, I'm writing an article for a Java magazine and would like to include in it a list of ten things every Wicket programmer must know. Of course, I have my list, but I'd be very curious to see what you think should be on that list from your own experience. Or, put another way, maybe the question would be what I wished I knew when I started Wicket - what tripped you up or what made you kick yourself later? Not ten things, but a few anyway. This is what I really try to get across in training classes: - Understand how models work, that they are a shared reference to a domain object, and they connect your components. If you find yourself shoveling data around manually, have a second, third and fourth look at it, you're probably doing it wrong. - Detach your models. There's a simple rule: Any model that you instantiate or that you get passed in from elsewhere you need to either - detach yourself - or pass it to another component, thus delegating the responsibility for detaching it. Detach it or pass it on. - Try to use as few instance variables in your components as possible. Use instance variables only for handling state completely internal to your component. Use models for everything else - that is, everything that might be visible from outside your component. Internal state is stuff that never leaves your component, neither to whomever called you, nor to anything you call. The latter includes components that you aggregate in your panel. This rule greatly simplifies refactoring later on. - Did I mention that models are important? :-) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ten things every Wicket programmer must know?
On Thu, 28 Jul 2011 11:10:30 +0300 Martin Makundi martin.maku...@koodaripalvelut.com wrote: * compressing code by use of ids matching property names combined with CompoundPropertyModel and/or PropertyListView Oh.. that will lead to fragility. It can, but in my experience it hasn't. Our domain objects rarely change, and if they do, our unit tests catch that immediately. The page doesn't even render if the property model doesn't work, so if you have a simple tester.startPage(MyPage.class); you're safe enough in most cases. This is actually a good point to make for the list: - Unit test everything you can using WicketTester. It doesn't do everything, but it's invaluable as a smoke test at the very least. If possible, try and check stuff like visibility and enabled state of your components too. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
A safer way to build PropertyModels, version 1.2
https://github.com/duesenklipper/wicket-safemodel As I wrote earlier on this list, SafeModel lets you turn the fragile strings of this: IModelString childNameModel = new PropertyModelString( myBean, child.name); ...into this, gaining refactor-safety: IModelString childNameModel = model(from(myBean).getChild().getName()); I have just built SafeModel version 1.2, with the following improvements: - fixed an oversight in the initial version: You can now use a model as your root object for the from() method. - Based on an idea from Matt Brictson, you can now quickly build LoadableDetachableModels using fromService instead of from: IModelUser userModel = model(fromService(userEJB.loadUser(42))); This is experimental. fromService may be refactored later to end up in a different class (but that would at worst force you to change imports, so no big deal really). As always, feedback is greatly appreciated! Carl-Eric www.wicketbuch.de - 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, version 1.2
On Thu, 28 Jul 2011 12:44:14 +0200 Thomas Matthijs li...@selckin.be wrote: ...into this, gaining refactor-safety: IModelString childNameModel = model(from(myBean).getChild().getName()); Does it require a default constructor? In the above example, myBean is any sort of regular Java bean. That means: regular getters and setters. Default constructors may not be needed, I did not test that. SafeModel does not instantiate your objects. PropertyModel (which is what I'm using under the hood) may run into issues, but I'd suggest just giving it a shot. It will fail quickly if it doesn't work :) Carl-Eric www.wicketbuch.de - 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, version 1.2
On Thu, 28 Jul 2011 09:04:31 -0700 Matt Brictson m...@55minutes.com wrote: 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)); You are correct on both counts. That was a typo in my example. I fixed it on the github page now. Thanks Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problem in ListView populateItem()
On Tue, 26 Jul 2011 06:10:29 -0700 (PDT) eugenebalt eugeneb...@yahoo.com wrote: li.add(new Label(bookId), new Model(a)); You're adding: new Label(bookId), new Model(a) That is a new Label and a new Model. You want: new Label(bookId, new Model(a)) which is a new Label with an id and a model. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
A safer way to build PropertyModels
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
Re: A safer way to build PropertyModels
On Thu, 21 Jul 2011 22:33:47 +0300 Martin Grigorov mgrigo...@apache.org wrote: Matt, You need first class functions. All cool JVM langs support them. Just peek your favorite. That is indeed true. However, just for the fun of it, I'm going to try and implement at least a limited version of this... :-) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best search engine framework to use with wicket
On Sat, 16 Jul 2011 03:41:19 -0700 (PDT) hariharansrc hariharan...@gmail.com wrote: can anyone suggest the best search engine framework for wicket Wicket doesn't really care what other frameworks you use beside it. Wicket does nothing but the UI layer, and for everything else you can use whatever you want. Use Hibernate or IBatis or JPA or whatever for your DB access. Use Spring or Guice or whatever for your wiring. Use Hibernate Search or Lucene or whatever for your searching. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: error - serialization
On Thu, 7 Jul 2011 12:36:45 +0200 Miroslav F. mir...@seznam.cz wrote: After investigation I will answer myself - it is bug in tomcat, if you are using tomcat 6.0.29 upgrade to 6.0.31. Sounds like an interesting bug. Do you have any more information on this? Carl, static variables are good if you are going to do something like DB connection factory and you will reuse existing connection. When you will do in your style you will make new connection in each request (it is expensive). It is more expensive manually, yes, but that is why I advised you to use tools like JPA or iBATIS that will manage the connection for you, or at least use a DataSource. Just keeping a static variable around *will* *break* your application, because it is not thread safe. As soon as you have more than one concurrent user, this will break. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: error - serialization
();
}
}
public static void closeStatement()
{
try
{
statement.close();
}
catch(SQLException e)
{
e.printStackTrace();
}
}
public static void makeCommit()
{
try
{
connection.commit();
}
catch(SQLException e)
{
e.printStackTrace();
}
}
}
-Original Message-
From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de]
Sent: Tuesday, 05. July 2011 10:37
To: users@wicket.apache.org
Subject: Re: error - serialization
Code. I suspect there's something going wrong within the
LoadableDetachableModel, for example. Can you show the code
of your page and model?
Carl-Eric
www.wicketbuch.de
On Tue, 5 Jul 2011 10:08:33 +0200
Miroslav F. mir...@seznam.cz wrote:
Code or project layout? Driver for ostgreSQL JDBC is in tomcat
lib directory and code is standard
init and usage code from jdbc.postgresql.org examples. It works
but from some reason just for first time. When I do F5 on page
or redeploy
project error occurs - see my original post (look at the end):
http://apache-wicket.1842946.n4.nabble.com/error-serialization-td36416
36.htm
l
Miro
-Original Message-
From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de]
Sent: Monday, 04. July 2011 20:47
To: users@wicket.apache.org
Subject: Re: error - serialization
Can you show some code?
Carl-Eric
On Mon, 4 Jul 2011 08:02:16 +0200
Miroslav F. mir...@seznam.cz wrote:
Driver is in classpath and is initialized. When I start
tomcat, it
works (load images from database) but when i redeploy or
reload page
(F5) it complains about java.sql.SQLException: No
suitable driver
found I have to restart tomcat and than it works again.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: error - serialization
Code. I suspect there's something going wrong within the LoadableDetachableModel, for example. Can you show the code of your page and model? Carl-Eric www.wicketbuch.de On Tue, 5 Jul 2011 10:08:33 +0200 Miroslav F. mir...@seznam.cz wrote: Code or project layout? Driver for ostgreSQL JDBC is in tomcat lib directory and code is standard init and usage code from jdbc.postgresql.org examples. It works but from some reason just for first time. When I do F5 on page or redeploy project error occurs - see my original post (look at the end): http://apache-wicket.1842946.n4.nabble.com/error-serialization-td3641636.htm l Miro -Original Message- From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] Sent: Monday, 04. July 2011 20:47 To: users@wicket.apache.org Subject: Re: error - serialization Can you show some code? Carl-Eric On Mon, 4 Jul 2011 08:02:16 +0200 Miroslav F. mir...@seznam.cz wrote: Driver is in classpath and is initialized. When I start tomcat, it works (load images from database) but when i redeploy or reload page (F5) it complains about java.sql.SQLException: No suitable driver found I have to restart tomcat and than it works again. -Original Message- From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] Sent: Sunday, 03. July 2011 23:22 To: users@wicket.apache.org Subject: Re: error - serialization That means you don't have the appropriate driver jar in your classpath. You need the PostgreSQL driver jar, put it on your classpath, and initialize it. Carl-Eric www.wicketbuch.de On Sun, 3 Jul 2011 23:08:40 +0200 Miroslav F. mir...@seznam.cz wrote: Still problem with no suitable driver found Does someone has experience with this and solved it? Miro - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: error - serialization
Can you show some code? Carl-Eric On Mon, 4 Jul 2011 08:02:16 +0200 Miroslav F. mir...@seznam.cz wrote: Driver is in classpath and is initialized. When I start tomcat, it works (load images from database) but when i redeploy or reload page (F5) it complains about java.sql.SQLException: No suitable driver found I have to restart tomcat and than it works again. -Original Message- From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] Sent: Sunday, 03. July 2011 23:22 To: users@wicket.apache.org Subject: Re: error - serialization That means you don't have the appropriate driver jar in your classpath. You need the PostgreSQL driver jar, put it on your classpath, and initialize it. Carl-Eric www.wicketbuch.de On Sun, 3 Jul 2011 23:08:40 +0200 Miroslav F. mir...@seznam.cz wrote: Still problem with no suitable driver found Does someone has experience with this and solved it? Miro - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: error - serialization
That means you don't have the appropriate driver jar in your classpath. You need the PostgreSQL driver jar, put it on your classpath, and initialize it. Carl-Eric www.wicketbuch.de On Sun, 3 Jul 2011 23:08:40 +0200 Miroslav F. mir...@seznam.cz wrote: Still problem with no suitable driver found Does someone has experience with this and solved it? Miro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CheckGroupSelector - set checked if all Checkboxes are already selected
Since there was no ticket filed yet for this, I created a new one: https://issues.apache.org/jira/browse/WICKET-3718 It contains a patch that adds this feature (I called it auto update) to CheckGroupSelector, and provides select-all components for the other types of checkboxes too. Please have a look at it and let me know whether it's any good :) Carl-Eric www.wicketbuch.de On Thu, 12 May 2011 15:31:16 +0200 Carl-Eric Menzel cmen...@wicketbuch.de wrote: I ran into the same issue some time ago and did some work on (I think) the CheckGroupSelector, as well as Javascript selectors for the other types of checkboxes. I'll see over the weekend whether I can extract all that into a useful patch. Once heapifyman opens the ticket, I'll attach it there. Carl-Eric On Thu, 12 May 2011 15:17:00 +0200 Martin Grigorov mgrigo...@apache.org wrote: It looks like CheckGroupSelector doesn't support that right now. Please file a ticket. Attaching a quickstart will make it easier for us and it will be improved sooner. On Thu, May 12, 2011 at 1:44 PM, heapifyman heapify...@gmail.com wrote: Hello, I have a CheckGroup and the CheckGroupSelector. Everythings working fine so far except for one thing. If I check all checkboxes in the group (manually or through checking the CheckGroupSelector), save this to a database and reload the page, the individual checkboxes are correctly displayed as checked but the CheckGroupSelector is not, i.e.I have to click the CheckGroupSelector twice to uncheck all the individual checkboxes. So how do I let the CheckGroupSelector reflect the current state of the individual checkboxes when the page is loaded? Thanks for any hints - 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: CheckGroupSelector - set checked if all Checkboxes are already selected
I ran into the same issue some time ago and did some work on (I think) the CheckGroupSelector, as well as Javascript selectors for the other types of checkboxes. I'll see over the weekend whether I can extract all that into a useful patch. Once heapifyman opens the ticket, I'll attach it there. Carl-Eric On Thu, 12 May 2011 15:17:00 +0200 Martin Grigorov mgrigo...@apache.org wrote: It looks like CheckGroupSelector doesn't support that right now. Please file a ticket. Attaching a quickstart will make it easier for us and it will be improved sooner. On Thu, May 12, 2011 at 1:44 PM, heapifyman heapify...@gmail.com wrote: Hello, I have a CheckGroup and the CheckGroupSelector. Everythings working fine so far except for one thing. If I check all checkboxes in the group (manually or through checking the CheckGroupSelector), save this to a database and reload the page, the individual checkboxes are correctly displayed as checked but the CheckGroupSelector is not, i.e.I have to click the CheckGroupSelector twice to uncheck all the individual checkboxes. So how do I let the CheckGroupSelector reflect the current state of the individual checkboxes when the page is loaded? Thanks for any hints - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Tue, 8 Mar 2011 17:43:29 +0100 Maarten Billemont lhun...@gmail.com wrote: On 08 Mar 2011, at 16:39, Pedro Santos wrote: I vote for solution 3: postpone the onInitialize call, possible to the first Component#configure execution. Then the problem of initialization code being executed for not fully constructed components go away. Fun fact: There is already a patch for that... I actually also thought of that, which is why I asked for the reason as to why initialize() is invoked as a result of components being added to a page. If it ends up not being necessary (delay the onInitialize to when it's called for any other component) then perhaps that's a fair middle ground. People can still use constructors if they like (though really, the only single *advantage* I can think of for this is that it means you don't have to go back and fix your existing codebase), and others are free to use onInitialize. I would like to use onInitialize for things that *need* to be done outside of the constructor. However, there are much better arguments than existing codebase for still allowing constructors. First, constructors are natural places to do stuff like that. Yes, they have limitations, and yes, PostConstruct exists for a reason, but that doesn't render constructors obsolete. Second, if you need to use any kind of parameters for stuff you do in onInitialize, you *must* store them in instance variables, even if you need them just once and could have long let them be garbage collected. Going purely post-construct would be a very bad idea for this reason. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Tue, 8 Mar 2011 17:46:26 +0100 Maarten Billemont lhun...@gmail.com wrote: This is a valid vote if we can come up with a way of not having random failure side-effects from mixing the two (which is the whole reason the the issue exists in the first place), without a final onInitialize and an exception in add(). If such a solution is not suggested in this thread, we're gonna need either a final onInitialize or an exception in add(). You can't have your cake and eat it too. I think there are good arguments for both constructors and onInitialize. But the developer needs to know what he/she is doing. I think that both options are useful and valid. This is certainly not a case of having the cake and eating it too. Constructor-only makes some initializations more difficult (though of course you can still use onBeforeRender or onConfigure, as we do now, after my patch had been rejected originally). onInitialize-only increases memory footprint and introduces conceptually unnecessary state by forcing you to carry *every* parameter via an instance field. Having both lets the developer choose the most appropriate strategy for the component at hand. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Thu, 10 Feb 2011 23:10:42 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:
the problem is indeed that you are sharing state between pages which
is not allowed. you are doing it via one page passing in an anonymous
SelectionCallback to another page, which is the same as passing in an
instance of one page to another.
So anonymous classes between pages are a complete no-go in 1.5? We have
used the template method pattern rather extensively in our current
program. Some pages have methods like onPreviousButtonClicked that are
used like this:
[in OriginalPage.java:]
setResponsePage(new SomePage() {
@Override protected void onPreviousButtonClicked() {
setResponsePage(OriginalPage.this);
}
});
There are other methods that do more than just setResponsePage, but
this illustrates the concept. Pretty much exactly like what is done
with such methods in components all the time.
How do you do this without anonymous classes, or have I misunderstood
something?
Thanks
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, 11 Feb 2011 09:53:21 +0100
Wilhelmsen Tor Iver toriv...@arrive.no wrote:
So the best is to create a proper class that is nested but not a
member class:
private static class BackSomePage {
private PageReference pageRef;
public BackSomePage(PageReference pageRef) {
this. pageRef = pageRef;
}
@Override protected void onPreviousButtonClicked() {
setResponsePage(pageRef.getPage());
}
}
That's what I feared this would come down to. I think this is rather
awkward to use and is definitely a step backwards from 1.4.
I can see the PageReference being necessary - but if one uses
PageReference instead of Page.this, what would the harm be in still
using the anonymous class, apart from the slightly larger memory
footprint?
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, 11 Feb 2011 11:51:12 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Especially since this would basically make any kind of anonymous class in a Page impossible. What about anonymous instances of, for example AbstractReadOnlyModel that are created in a page and passed on to its components? And quite possibly also passed on to other pages from there. Is this all going to be forbidden now or am I missing something? Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dynamic CSS Resources and clustered wicket app
Hi, seems to me you should probably use sticky sessions in your loadbalancer ;-) I think if your resource depends on instance variables in your Page you really need to do that. If you just depend on stuff happening in the initialization of the Page class (not an instance) you could use an Initializer that gets run on application startup. See org.apache.wicket.IInitializer for details. Carl-Eric www.wicketbuch.de On Thu, 09 Dec 2010 11:22:54 +0100 Chris Wewerka christian.wewe...@1und1.de wrote: Hi, I've used the approach described in https://cwiki.apache.org/confluence/display/WICKET/Dynamically+Generate+a+CSS+Stylesheet for dynamic CSS and js files. (already added my comment, point 5) But I've experienced a problem in our live cluster (two tomcats with apaches and a loadbalancer) For example, if server1 and server2 sit behind a loadbalancer and your wicket app is freshly started it might happen, that the first user gets directed to server1, from which he gets the start page. This page may include dynamic css like above which the browser now loads in a separate request which maybe gets delegated to server2, which maybe has never initialized the start page. Now the wicket app from server2 serves the css without resolving the variables. I'm scanning through the wicket resources, especially SharedResources.java and PackageResource but I'm not sure how to solve the problem since CSSPackageResource is for static resources and DynamicWebResource is in a different branch of the Resource hierarchy, so before writing my own DynamicCSSResource implementation, I wanted to ask if someone else had the same problem and if there is already a solution for it, which I didn't find yet. Regards Chris - 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: Dynamic CSS Resources and clustered wicket app
Hi, if you can initialize your resource in a page constructor, you can do the same thing with an IInitializer. You could create shared resources there, for example - then just use any of the applicable resource classes and use TextTemplate for interpolation. Carl-Eric www.wicketbuch.de On Thu, 09 Dec 2010 12:38:23 +0100 Chris Wewerka christian.wewe...@1und1.de wrote: Hi, thanks Carl-Eric. We're using sticky sessions already and the config seems to work for everyting except CSS files. I've just seen that the browser also sends the cookie containing the jsessionid along with the css request, so maybe our sticky session config is wrong here. Already wrote the admin a mail about that. So, but I think we can also pre initialze our css resources. Our CSS contains paths to images which vary only between staging and do not depend on page params. The problem is that it's not static, so we can simply use PackageResource, but we have to interpolate our variable for the imageserver. PackageResource uses the configured ResourceStreamLocator which in turn uses the configured IResourceFinder which is per default org.apache.wicket.util.file.WebApplicationPath. This buddy uses an FileResourceStream and here I have to intercept: Write a separate impl. of WebApplicationPath which uses an TextTemplate instead of an FileResourceStream, and configure this in the application so that Application.get().getResourceSettings().getResourceFinder() returns my interpolating implementation. Is there a simpler way for this? Best regards Chris On 12/09/2010 11:48 AM, Carl-Eric Menzel wrote: Hi, seems to me you should probably use sticky sessions in your loadbalancer ;-) I think if your resource depends on instance variables in your Page you really need to do that. If you just depend on stuff happening in the initialization of the Page class (not an instance) you could use an Initializer that gets run on application startup. See org.apache.wicket.IInitializer for details. Carl-Eric www.wicketbuch.de On Thu, 09 Dec 2010 11:22:54 +0100 Chris Wewerkachristian.wewe...@1und1.de wrote: Hi, I've used the approach described in https://cwiki.apache.org/confluence/display/WICKET/Dynamically+Generate+a+CSS+Stylesheet for dynamic CSS and js files. (already added my comment, point 5) But I've experienced a problem in our live cluster (two tomcats with apaches and a loadbalancer) For example, if server1 and server2 sit behind a loadbalancer and your wicket app is freshly started it might happen, that the first user gets directed to server1, from which he gets the start page. This page may include dynamic css like above which the browser now loads in a separate request which maybe gets delegated to server2, which maybe has never initialized the start page. Now the wicket app from server2 serves the css without resolving the variables. I'm scanning through the wicket resources, especially SharedResources.java and PackageResource but I'm not sure how to solve the problem since CSSPackageResource is for static resources and DynamicWebResource is in a different branch of the Resource hierarchy, so before writing my own DynamicCSSResource implementation, I wanted to ask if someone else had the same problem and if there is already a solution for it, which I didn't find yet. Regards Chris - 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 - 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: Dynamic CSS Resources and clustered wicket app
On Thu, 9 Dec 2010 13:21:47 -0600 Jeremy Thomerson jer...@wickettraining.com wrote: Not really. You could have dynamic resources referenced in your constructor that depend on instance variables, or the model that was passed into the constructor, etc For anything that doesn't need that, you are right: it's better to use a shared resource. But, if you must rely on state from the page, you can't really use a shared resource. Well, yeah. My second message was poorly worded in that regard, but that's basically what I said initially. Use sticky sessions ;-) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:49:32 -0500 James Carman ja...@carmanconsulting.com wrote: Are you moving a field from one form to another? But that does change the semantics, doesn't it? If it doesn't, why are there two forms? Both forms edit one particular object (say a Person). They just edit different values on the same object. Again, I'm not sure this is the best example, but it's at least plausible. So either there is a difference between the forms (different submit method maybe?), then this move would make a semantic/behavioral difference and needs to be done in code. Or there is no difference at all. Why are there two forms then? Just use one. No offense meant, but this does not seem to be a plausible example to me. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 12:17:38 -0800 Igor Vaynberg igor.vaynb...@gmail.com wrote: i wonder if queuing can actually replace icomponentresolver and auto-adding. i wonder if after onbeforerender we can do what unqueing does now, parse the markup, find any missing components, and insert them. autocomponents and autoadd() is something ive always disliked because it doesnt work for anything that needs to stick around across requests. I was initially opposed to the liquid hierarchy idea, and still do not like the original proposal. *This* however makes things much more interesting. I think this may actually be useful. Initial thoughts about this: What about the assumptions in onBeforeRender? What are the consequences of having the queued components available only after that phase? Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 12:16:00 -0800 Igor Vaynberg igor.vaynb...@gmail.com wrote: the difficult part is that doing this to complex pages is...difficult. in the example above it is easy to see the two components that need to be renested. but, in complex pages there can be 20 components that need to be renested, and they are probably initially added from a bunch of helper methods that attempted to keep the code clean. so, it may be difficult to find all 20 componets. queuing can make maintenance and refactoring of pages easier. I can see how it might make it somewhat easier, but it seems to me that one is treading on rather thin ice. And speaking of these helper methods: Maybe it's my increasingly functional style coming from some exposure to Scala, but I really hate it when these methods add stuff behind my back to anything else than the component they're returning. yes, ive had to do it plenty times. ive had to go into pages that were already written and ajaxify them. sometimes a table needs to be updated via ajax, it needs to be wrapped in a container. other times a set of related form fields needs to be updated, its easier to wrap them in a container and update it rather then having to add them one by one from multiple places. But wouldn't such a page be a prime candidate for a proper refactoring anyway? I'm getting a quick dirty feeling. IMHO valid use cases have not been provided yet. we can agree to disagree Certainly, especially since you do make some valid arguments. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Wed, 10 Nov 2010 07:31:28 -0500 James Carman ja...@carmanconsulting.com wrote: On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: So either there is a difference between the forms (different submit method maybe?), then this move would make a semantic/behavioral difference and needs to be done in code. As I said, the two forms edit different values on the same object. Yes, this change would be a semantic/behavioral change, but you could actually do it with just a change in the markup. It wouldn't require a change to the code. This is assuming you queue the fields onto the containing panel and not onto the contained forms, which is entirely possible (and even likely). How many times have you accidentally called add() when you meant to call rowItem.add() in a repeater? With the queue() method, you wouldn't get an error message saying the markup doesn't match. It would just figure it out and you'd be none the wiser. That's exactly my point :-) This is not a good example to allow queuing, because there's no gain. Either there is an important difference between the two forms, then it doesn't make sense to queue *above* the forms, or there is no difference between the forms, then you can just have *one* form and not need queue at all. By needs to be done in code I mean that it is not something that should be doable in markup. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi, no offense meant, but the rhetoric in this thread is getting more and more ridiculous. Chicken? Component hierarchy hell? Seriously? At most maybe component hierarchy slight annoyance. I am not at all convinced that this is a good idea. In my opinion, one of the strongest and best points about Wicket is that it has a set of very clear and logical concepts and does not deviate from them. I especially like the fact that the truth is in the code and the code rules, period. Unlike Tapestry, where you could pull all kinds of stunts by using a special notation in the ID attributes of markup elements. The next thing is going to be that some developers don't want to touch the code just because the designer wants a login panel on this other page too. So why can't the designer write wicket:instantiate class=foo/? It's just another hierarchy element, isn't it? I frankly don't see any way to have this auto-hierarchy stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing. The loss of predictability and clear concepts isn't worth the very slight gain in... well, gain in what? In the ability to let code and markup drift apart? To be honest, I don't even see the possible gain with this change. So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. Not even in our sprint retrospectives, where people are specifically asked to complain! Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:20:12 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: I frankly don't see any way to have this auto-hierarchy stuff without getting lots of unnecessary ambiguity and sources of bugs. I totally agree with what Eelco wrote below, and what someone else said about the Python way of having only *one* way to do *one* thing. Would you be happy if there was an application level configuration switch: getMarkupSettings().setAllowComponentAutoHierarchy(true); Possibly. I'd rather not have the unnecessary complexity of this feature at all though. I certainly wouldn't want to support it if I was a wicket developer :-) Which is default false? This way you can make sure nobody in YOUR project messes things up? I have new projects every now and then, and most of them are already underway when I get called in. Which is why I like toolkits that do not encourage sloppiness(*). Carl-Eric www.wicketbuch.de *) sloppiness != easy to write I'm all for static typing, since it saves me the work of checking the types. I'd like it to be more like Scala, which saves me the typing I have to do in Java, while still giving me the same guarantees. With your proposed config switch, you're basically giving up one of Wicket's guarantees, the one that the hierarchy is what it looks like in the code. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:23:27 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. heree I can only ask you: Have you ever seen friction with your own eyes? Coding friction? Yes. Every time I need to look at somebody else's code and try to figure out what exactly they did. And as a consultant (I know, I said the nasty word) that is a pretty big part of what I do. Please consider the needy ones that would have to deal with this and would have to support people who made the mistake of using it :-) It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. If you only write code and never read or need to fix it. It might not be for everyone, but please don't deprive the needy ones. Well that certainly applies the other way around too. It's not for everybody, so please don't introduce a new source of bugs into *this* toolkit. Also, unless I missed a message (which is possible), so far we seem to have a needy *one*, not *ones*. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
This is pretty much exactly what I'd do given such a requirement. If something is so different as to require a different internal hierarchy, it's no longer the same component. Make a new component and use standard OO techniques for code reuse, like Frank wrote here. This certainly is not worth the can of worms that's being opened right now. Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:46:54 -0600 Frank Silbermann frank.silberm...@fedex.com wrote: Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components. Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin Matt On 2010-11-09 13:34, Martin Makundi wrote: Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 14:21:46 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Here we finally come to an actual argument about this: Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. Frank wrote in another message how to deal with this case. I agree with him and add: If your new panel is so different from the old panel that it requires a different internal hierarchy, it's no longer the same component. Use standard OO techniques to deal with it. Also, think about whether your component design (as in what parts form a component, and what parts don't) is correct. Seems to me that in such a case too many things have been thrown together that should not be together. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:01:28 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Coding friction? Yes. Every time I need to look at somebody else's code and try to figure out what exactly they did. Ah.. so you are trying to solve your problem probably from the wrong end? If you have bad warriors give them plastic swords so they can hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies, Dream teams, ... So a clear architecture is a plastic sword? And do whatever you want is better? Please consider the needy ones that would have to deal with this and would have to support people who made the mistake of using it :-) I don't think there is a substitute for coding skills/talent ;))) There isn't. That's not the point. So far your argument seems to be #1 I don't like this and #2 those who don't agree with you aren't good coders. It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. If you only write code and never read or need to fix it. I understand if you are a consultant it gives you plenty of billable to code again and again. WTF? Your argument #3 is that *I* want to screw my customers over? Seriously? But my sweetspot is product development and I need to make flexibly reusable components and unfortunately requiring html hierarchy to match on different pages makes really messy code on java side if I try to implement free-from-iherarchy in a manual way (I must provide various different parent containers to a generic component so that it can land in the right place). This just doesn't make sense. Put your stuff in a panel, then it's a self-contained component and insulated from the hierarchy of the page and other components. Then you can put that component wherever you want. Well that certainly applies the other way around too. It's not for everybody, so please don't introduce a new source of bugs into *this* toolkit. Also, unless I missed a message (which is possible), so far we seem to have a needy *one*, not *ones*. Still, I don't think there is a substitute for coding skills/talent ;))) And I still haven't yet seen a convincing example of this being a problem worth adding the complexity. Then again, in the end the Wicket devs need to decide on whether they want to support this or not. So far *my* definitely non-binding vote is -1 :) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:05:39 -0500 James Carman ja...@carmanconsulting.com wrote: I think we need to try to put our heads together on this one. I don't necessarily think this approach is the best, but I haven't really had a chance to wrap my head around it yet, frankly. Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? Perhaps you can create a new container component that does all of this stuff with some pre-render magic or something? If you want to use it, you can. If not, you don't have to. So, if you're the type that likes this loosey goosey stuff, you basically wrap your pages with one of these things to enable this type of behavior. I don't know. This is just off the top of my head. Still not done with my morning coffee. +0.5 If this can be done with a special-case container (HighlyDangerousLiquidHierarchyMarkupContainer ;-) ), I wouldn't really mind, as long as the impact on the rest of the framework is small. I do not think it's worth it to change the whole framework around this special case. Especially since things like enabling/disabling of components based on their parents in the hierarchy don't seem to have been addressed yet. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 17:23:18 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: So instead of asking, How can we make Wicket different so that my problem will go away? the proper question to try first is, What is the Wicket way of solving my problem? That's not how proggress is made... So far you are *still* the only one in favor of this whole idea. You have not really replied to any of proposed solutions except with [paraphrased] I don't want to do it that way or some silliness about child's play. At the same time, you have not responded to valid criticisms like the problems with enabledInHierarchy (at least I haven't seen any such response). I finally understand your problem now that it has been defined somewhat, but I do not think your suggestion is a good solution to it. There are other solutions with a much smaller impact. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 17:46:13 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: @Carl-Erik Reason why I haven't commented your enabledInHierarchy comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 10:51:49 -0500 James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann frank.silberm...@fedex.com wrote: If the component hierarchy can be changed without changing behavior or semantics, then why are the components in a hierarchy to begin with? Why aren't all the components being moved around already siblings at the same level? Does Wicket require that the order of sibling Wicket components match the order at which simply HTML elements appear? You could do that, but I think Martin is trying to take it a step further allowing you to have an arbitrary hierarchy in your markup and just figure it out at runtime. Wicket doesn't care what order you add stuff to the page/component as long as they're all on the same level within the hierarchy. I think you misunderstood Frank's point. Why are the components in a hierarchy in the first place, if the hierarchy can be changed without changing behavior or semantics? They can simply be flat in the parent then. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 18:04:44 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Igor explained that # Components can be queued to any container, and can only be added to the hierarchy that stems from that container, thereby solving the security requirement https://github.com/ivaynberg/wicket/tree/component-queuing Having read the readme there, this is starting to finally make some sense. This proposed solution might actually work without too much breakage. I still don't see the necessity for this change, but I'm willing to change my -1 to a -0.5. I'll go for a -0 if it can be shown that the impact of this on the rest of Wicket is minimal (i.e., it needs few code changes and doesn't break any assumptions in framework or user code, for example about when exactly the component tree is available). Carl-Eric www.wicketbuch.de PS: I think much of this controversy could have been streamlined by pointing to a concept-complete implementation or at least making a properly thought-out suggestion, instead of all the name-calling that went on. (Almost) No offense taken, just a suggestion for the future. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:33:31 -0500 James Carman ja...@carmanconsulting.com wrote: Say you have two forms on one panel (don't know if this is the best example or not, but here goes). You want to move a field from one panel to another. You'd have to do that in code with the traditional approach. With the queued approach, you'd just queue all your components to the parent container and it would auto-add them to the correct subcomponent as it finds them in the markup. Are you moving a field from one form to another? But that does change the semantics, doesn't it? If it doesn't, why are there two forms? With this, the order does matter, though. Suppose you had two components you wanted to queue with the same id, completely different components. If you reverse their order, then they're auto-added in a different order. Ouch. I think this has the potential to be a showstopper. This will be an endless source of hard-to-find bugs. I think there needs to be a unique-id requirement when you start using queue. Right now we require unique-ids on the same hierarchy level, i.e. direct descendants of the same component. With queue, we're basically extending necessity that to the whole subtree. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
New german Wicket book
Hi Wicket devs and users, I'm proud to announce the release of our new german-language Wicket book: Wicket: Komponentenbasierte Webanwendungen in Java by Roland Förther, Carl-Eric Menzel and Olaf Siefart. Published by dpunkt Verlag (many thanks to René Schönfeldt and the others at dpunkt). More information is available at http://www.wicketbuch.de/. A few words in german on availability: Die Auslieferung an den Buchhandel hat gestern begonnen, bei den meisten Händlern müßte das Buch Ende dieser Woche oder spätestens Anfang nächster Woche verfügbar sein. Es sollte also zu Weihnachten noch reichen :-) Carl-Eric -- Carl-Eric Menzel Das neue deutschsprachige Wicketbuch: Wicket: Komponentenbasierte Webanwendungen in Java http://www.wicketbuch.de/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket 1.4 takes type safety to the next level
On Thu, 30 Jul 2009 12:54:29 +0200 Martijn Dashorst dasho...@apache.org wrote: The Apache Wicket project is proud to announce the release of Apache Wicket 1.4. Congratulations to the team and all contributors, and a big thank you! Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.4 is ready for production?
On Tue, 21 Jul 2009 00:00:04 +0300 Martin Makundi martin.maku...@koodaripalvelut.com wrote: No. It crashes. Restart your browser and you will see. Works for me. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Conversation scope in wicket
+1 I fully agree. Conversation scope is a kludge for a broken model, and in the end nothing more than a specialized form of global variables. Just put your state into the appropriate page or component instances and/or models, and you get *any* scope you need, for free. Carl-Eric On Thu, 18 Jun 2009 01:55:26 -0700 (PDT) svenmeier s...@meiers.net wrote: What is this 'conversation' all about? It doesn't seem to be a known concept in any GUI guideline I know (e.g. Apple's Human Interface Guidelines). Neither does wikipedia list it under http://en.wikipedia.org/wiki/GUI_widget. This is what wikipedia is saying about Seam's conversation: 'The default Seam context is conversation which can span multiple pages and usually spans the whole business flow, from start to finish.' This seems to describe a http://en.wikipedia.org/wiki/Wizard_(software) . IMHO 'conversation' is a buzzword invented for those who still think a web UI consists of a sequence of HTML pages only. Back in 2000 the same guys invented 'mvc-2' and told us that a UI can be built on actions only. Just my rant (worth 2 cents or less). Back to Wicket and wizards: For a wizard I'd suggest to use a single Wicket page, replacing components as you step through it. Note that Wicket extensions provide a wizard component, but you can easily roll your own implementation. Sven Hican this functionality added to the standard wicket? actually much of seam popularity came from supporting conversation scope..., so i think that adding explicit wicket support will have momentum i think that having just a store for conversation objects will be a good begin then we may add apis like beginConversation, endConversation ,joinConversation,mergeConversation ,suspendConversation,resumeConversation and other concepts like workspace what do u think? Joe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Conversation scope in wicket
On Thu, 18 Jun 2009 07:21:36 -0400 James Carman jcar...@carmanconsulting.com wrote: I fully agree. Conversation scope is a kludge for a broken model, and in the end nothing more than a specialized form of global variables. To which model are you referring? Not a model in the Wicket sense, but the model of application development where you throw everything into a big bag (e.g. the session, or any other such scope). Just put your state into the appropriate page or component instances and/or models, and you get *any* scope you need, for free. Your business logic might not know anything about page/component instances, but it may support conversations. Then you already have an object that your components can work on. Put that in a Wicket model and enjoy. My point is this: You either have existing business code that supports conversations - then you don't need Wicket conversations, you need to write your components so they work with the existing code's notion of a conversation. Or you don't have a business conversation, and the whole conversation thing is just something for UI workflow. Then you should not have it in the business code. Instead, write components and models so that they keep all the state they need for this conversation where they need it. I don't think there needs to be a special abstraction for this, you'd be much better off with keeping state as appropriate for your use case. I may have been unclear in my earlier message, does this make more sense? Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Conversation scope in wicket
On Thu, 18 Jun 2009 08:10:33 -0400 James Carman jcar...@carmanconsulting.com wrote: On Thu, Jun 18, 2009 at 7:46 AM, Carl-Eric Menzel cm.wic...@users.bitforce.com wrote: Then you already have an object that your components can work on. Put that in a Wicket model and enjoy. My point is this: You either have existing business code that supports conversations - then you don't need Wicket conversations, you need to write your components so they work with the existing code's notion of a conversation. Wicket needs to understand when it needs to resume a previously-begun conversation. The business logic can't know that by itself. The UI has to provide a bit of help. Yes of course. That's what I meant by write your components so they work with your existing code. The idea of a conversation has been around for a long time. It's called a stateful session bean. You have a point there. But I think this is all provided by Wicket already - You have components and models that perfectly encapsulate all this. Basically this is about the lifecycle of the data needed for a unit of work from the user's point of view. If you have a flow of pages, or wizard steps, or whatever, you have a defined starting point where you can, for example, create a model. And then you go to the next step and pass this model along. Once you're finished, you just drop the references. Or am I missing something here? Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Problem with Maven archetype, Eclipse Classpath and jetty:run
Hi, when creating a fresh Wicket project with the following line as generated by the quickstart page on wicket.apache.org: mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.4-rc4 -DgroupId=com.mycompany -DartifactId=myproject ...I run into a number of (easily fixable, but somewhat annoying and non-obvious) problems. - The classpath file generated by 'mvn eclipse:eclipse' has an include-pattern of '**/*.java' for both src/test/java and src/main/java. This means that by default none of the HTML files or other resources will be copied to the classpath when for example using the 'Start' class. This can of course be fixed by manually removing these restrictions from the classpath, but on regenerating with eclipse:eclipse they will be added again. Also, this is probably non-obvious to new users. I think this is more of a Maven problem than one with Wicket, but it shows up as more of a problem here because not many other projects have their resources directly in the packages. I have not found an option in eclipse:eclipse to set these include patterns. Does anybody know whether any such options exist? If yes, I propose adding an appropriate setting to the Wicket archetype. If not, I think there should be a notice about this quirk on the quickstart page. I realize this is probably due to the fact that Maven wants to copy the resources itself, so it can do its filtering. However, I don't really see that as an issue for a typical Wicket project, or am I missing something? The second problem is due to the way I set up my project -- it may be odd (is it?), but I think this is rather sensible for standalone component development. - I am developing a standalone component for use in other projects, so under src/main/ I'd like to have only the classes and resources that belong to the component. On the other hand, for testing and debugging purposes, a simple Wicket application and page are very handy, so I moved those from src/main to src/test, since these shouldn't show up in the generated jar file. This works in Eclipse when I remove the restrictions mentioned above from both src/main and src/test. When I try to use 'mvn jetty:run', it breaks down, complaining that it can't find the Application class (and by extension also the other classes in src/test). This is fixable by adding configuration useTestClasspathtrue/useTestClasspath /configuration to the jetty-plugin part of the generated pom.xml. I don't see any negative side-effects of this, so I'd like to propose adding this to the archetype. As an aside: Is this practice of keeping a debug Application under src/test considered good or bad practice? If bad, why? Best regards, and thanks for a great framework! Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxEditableLabel ... but how to get the changed value?
On Tue, 26 May 2009 16:27:18 +0200
Dorothée Giernoth dorothee.giern...@kds-kg.de wrote:
Now I want to write the changed information from these labels back
into the database after the content has changed. Wouldn't be too much
of a problem if I knew how to retrieve the changed value from the
label. I really have no clue how to do that!
Override the onSubmit() method, like this (untested, but you get the
gist):
cell.add(new AjaxEditableLabel(cell.newChildId(), new Model(...)) {
protected void onSubmit(AjaxRequestTarget target) {
super.onSubmit(target);
String value = getDefaultModelObject();
// persist value here...
}
});
Alternatively, if you keep a reference to the model you pass to the
AjaxEditableLabel, you can read its contents at some other point.
Grüße
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Problem with Maven archetype, Eclipse Classpath and jetty:run
On Tue, 26 May 2009 08:31:04 -0700 Igor Vaynberg igor.vaynb...@gmail.com wrote: go to preferences/compiler/building/output folder and remove *.html from Filtered Resources list. I know that :-) I was proposing making this the default in the archetype. test is for tests :) the proper way to do this is to create a multimodule project - one module containing the component and another containing a demo which you can also use for testing. Interesting idea, I'll try that. But I need a page if I want to test a form (and thus testing how my component acts within the form), don't I? WicketTester.newFormTester seems to want to have a page started first. That's why I wanted to have the page in the test directory, because I only need it as a test fixture. Thanks for the reply Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Fw: Problem with Maven archetype, Eclipse Classpath and jetty:run
On Tue, 26 May 2009 08:39:36 -0700 (PDT) Juan Carlos Garcia M. jcgarc...@gmail.com wrote: [MECLIPSE ticket and workaround] Hope this help. Yes it does, thank you. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: clarification on page versioning
Both Login and CurrentProfile are subclasses of Panel. When the login form is submitted or the logout link is submitted, in order to get the page to re-render, I had to use this code: setResponsePage(getPage().getClass()); In this case the page isn't re-rendered, it is re-created, i.e. a new instance of your page class is instantiated, which then does the add(new CurrentProfile()) in its constructor. In the default behavior you're getting the exact same page instance you initially created and in which you said add(new Login()). To replace the login panel with the profile panel, keep a reference to the login panel and in your form submit method do this: login.replaceWith(new CurrentProfile()) This removes the login panel from the page and, as the method name suggests, replaces it with the CurrentProfile instance. Remember the latter in a field too, if you ever want to switch back. This way you only have one page and swap out its components instead of creating new page instances. Hope this helps Carl-Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
