Re: Externalized Page Flow in Wicket
Yes, I uploaded it with no fanfare to the 1.4 branch of wicket-stuff and intended to port it to 1.5 then make an announcement. But since you asked here is the code: https://github.com/wicketstuff/core/tree/core-1.4.x/jdk-1.5-parent/spring-webflow-parent You can see an example app in the spring-webflow-examples module. It should run fine with Jetty. -Clint On Wed, Jan 11, 2012 at 8:28 AM, vasanth vasan...@gmail.com wrote: Hi Clint, We have a similar requirement where we want to externalize the page flow to work with Spring Web Flow. Have you shared the integration layer anywhere or do you have any write up on how you did this? Thanks. --Vasanth -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Externalized-Page-Flow-in-Wicket-tp3515182p4285773.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Wicket source code moved to Git
Jeremy, Will Git development mimic the current subversion workflow, or will we see we see a more Git-ish way like 'git flow'? See- http://nvie.com/posts/a-successful-git-branching-model/ I realize that likely the answer is 'we don't know yet', so I'd like to get the conversation going. -Clint On Tue, Dec 20, 2011 at 10:04 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Our SVN repository is now set read-only. For information about getting started with Git @ ASF, see [1]. The JIRA issue where we were converted is [2]. Unfortunately I will not be able to experiment much (if at all) with this until tomorrow night. Feel free to reply to this thread if you have problems migrating. I'll try to help work through those. For now you are not allowed to push any commits that have the Git committer field set to a non-Apache email address, although I hope that requirement will change very soon. Is there a volunteer willing to get our build infra set up with the new Git repo? [1] http://git-wip-us.apache.org/#committers-getting-started [2] https://issues.apache.org/jira/browse/INFRA-4204 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Remember Frappr? (Mapping Wicket users)
I was wondering the other day if there were any Wicket developers in various European countries. Long ago while contributing to TiddlyWiki we had used frappr for that purpose. It appears that there had been a similar one for Wicket: http://martijndashorst.com/blog/2006/02/19/wicket-group-at-frappr/ Unfortunately it appears that frappr was bought out, then taken offline. Is anyone aware of an equivalent service? It's fun to see where everyone is from. -Clint
Wicket Stuff commit access
Please grant commit access to user name 'checketts' and 'fbraun' We'll be uploading the Wicket and Spring WebFlow integration code.
Re: Roadmap for Wicket 6
I'd second 'rework examples into proper tutorial app', and aim for it a beginning section to be a step by step intro to new concepts, like an 'intro to wicket' app that has a sequential setup (ie #1 getting started, #2 navigating between pages, #3 pageparameters) etc. * rework examples into a proper showcase app -igor On Mon, Aug 29, 2011 at 3:12 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: In order to start discussing what will constitute Wicket Next and where we want to take our beloved framework, I'll start off with my wish list: 1. Java 6 as a minimum requirement for *all* of wicket 2. Servlet API 3.0 as a minimum requirement 3. JavaEE 6 support for at least CDI 4. Proper OSGi support 5. Ajax refactoring to use JQuery and provide proper JQuery integration in core 6. Shorter release cycle I +1000 #1 in my wish list, since then I'll be able to build releases again. Regarding #6 I aim to release Wicket 6 final in December. Martijn
Re: ISecuritySettings.setEnforceMounts(boolean)
Instead of dropping it would you prefer I submit a patch that re-enables it? -Clint On Tue, Jun 28, 2011 at 7:36 AM, Martin Grigorov mgrigo...@apache.orgwrote: Yes. This setting is ignored in current trunk. On Tue, Jun 28, 2011 at 3:10 PM, Clint Checketts checke...@gmail.com wrote: We use setEnforceMounts(). Would that be broken too by this change? Ws Martin saying that BookmarkableMapper isn't using the setting at all in 1.5? -Clint On Tue, Jun 28, 2011 at 4:49 AM, Martin Grigorov mgrigo...@apache.org wrote: OK, I'll remove it. Seems easy enough to re-add if someone ever need it. On Mon, Jun 27, 2011 at 6:11 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i think we can drop this from 1.5 -igor On Mon, Jun 27, 2011 at 3:14 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, In 1.5 org.apache.wicket.settings.ISecuritySettings.getEnforceMounts() is not currently used. Reading its javadoc I understand that it should disable completely org.apache.wicket.request.mapper.BookmarkableMapper when the flag is true. I.e. making a request to /wicket/bookmarkable/com.example.MyPage should not be recognized by BookmarkableMapper. Am I right ? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Rework AttributeModifier to deprecate AttributeAppender and SimpleAttributeModifier
So AttributeAppender and SimpleAttributeModifier will not be deprecated? On Thu, Jun 9, 2011 at 10:24 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I've committed the rework for 1.5, which doesn't completely rework AttirubteModifier and friends, but sets the stage for 1.6. I didn't want to break too much API this late in 1.5 See: WICKET-3783 for details. Martijn On Thu, Jun 9, 2011 at 5:23 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: In short: AttributeModifier can get a lot simpler: - always add the attribute (unless the AM is disabled) - the regexp matching functionality needs to go - replaceModel needs to become an Object (with instanceof check for models) - enabled field should be removed in favor of subclassing and overriding isEnabled() This will clean up AttributeModifier considerably—not catering for extreme use cases. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com
FormComponent convertInput
I have a FormComponentPanel that contains multiple child formcomponent. The
purpose of this panel is to be able to add in several cihldren dynamically.
The end model is supposed to be the list from all the children component. I
get the value in my convertInput() method by iterating over all the children
components, calling each one's getConvertedInput()
Here's the problem, the child component's values haven't convertedTheir
input at that point, so i call 'validate()' on each one to trigger that
coversion. Is that the right way to approach this? Am i causing
unneeded/duplicate processing?
.
protected void convertInput() {
final ArrayListT convertedInputList = new ArrayListT();
inForm.visitFormComponents(new IVisitor() {
public Object formComponent(IFormVisitorParticipant formComponent) {
if (formComponent instanceof FormComponent?) {
FormComponentT fc = (FormComponentT) formComponent;
*fc.validate();
* T convertedInput = *fc.getConvertedInput();
* if(null != convertedInput){
convertedInputList.add(convertedInput);
}
}
return Component.IVisitor.CONTINUE_TRAVERSAL;
}
});
setConvertedInput(convertedInputList);
}
Thanks,
-Clint
Re: Wicket help
The magic is calling setVariable on the ConversionException. Thanks to Igor's
new book https://www.packtpub.com/apache-wicket-cookbook/book for teaching
me that. ;)
So in your page's property file you'd have (you had the wrong case on
*IC*onverter
in your last email):
mortgageAmountPrimary.IConverter.Double=You must enter a valid value for
${user}'s mortgage amount field to continue with this application.
Java code:
form.add(new
TextFieldDouble(mortgageAmountPrimary,Double.class){
@Override
public IConverter getConverter(Class? type)
{
return new DoubleConverter(){
@Override
public Double convertToObject(String value, Locale
locale)
{
try{
return super.convertToObject(value, locale);
}catch(ConversionException e){
* e.setVariable(user, Theos);*
throw e;
}
}
};
}
});
I did it all inline so you could see it. But subclassing to make it more
useable, like getting the variable's value via a passed in Model wouldn't
hurt.
-Clint
On Thu, Mar 31, 2011 at 4:54 PM, Henry, Mike [GCG-PFS]
mike.he...@primerica.com wrote:
I have:
TextField mortgageAmountPrimary = new TextField(mortgageAmountPrimary,
Double.class);
If the built in double conversion fails I want this custom error
message:
You must enter a valid value for Ted's mortgage amount field to
continue with this application.
I need to pass in Ted in a variable like:
mortgageAmountPrimary.Iconverter.Double=You must enter a valid value for
${username}'s mortgage amount field to continue with this application.
So I need a 'username' var to pass in. Can you extend a converter and if
so how would you instruct the textfield to use it?
Thanks
-Original Message-
From: Jered Myers [mailto:jer...@maplewoodsoftware.com]
Sent: Thursday, March 31, 2011 3:39 PM
To: dev@wicket.apache.org
Subject: Re: Wicket help
I think you might be looking for the variablesMap(IValidatable) function
in AbstractValidator. You will probably need to extend your validator
and override that function. PatternValidator overrides it to create the
pattern variable, if you want an example.
On 3/31/2011 10:57 AM, Henry, Mike [GCG-PFS] wrote:
Does anyone know if its possible to add your own variables to the
built it converters/validators for custom messages?
Re: 1.4.16 - adding methods to IBehavior
So in theory a behavior implementing this could add additional components to the page? Or is the hierarchy frozen at this point? On Friday, February 18, 2011, Jeremy Thomerson jer...@wickettraining.com wrote: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: final Page.onInitialize()
Hans,
I'm agreeing. I'm just saying that if you start treating the onIniliaze() as
the place to create your components then you are stuck with the same problem
as before:
class MyPage {
MyPage() {
}
* onInitialize() Using onInitialize in the page doesn't give you
anything, so that is why its 'final'
add(new MyPanel());
}*
}
class MyPanel {
MyPanel() {
log.debug(getPage() = + getPage()); = null
add(new Label(id, getString(resKey)); = does not resolve
}
}
On Thu, Feb 10, 2011 at 2:08 AM, Hans Lesmeister 2
hans.lesmeis...@lessy-software.de wrote:
Hi,
Clint Checketts wrote:
I don't believe the goal of onInitiallize is to move all component
creation
from the constructor to onInitialize, since if you are adding the
component
to the parent in the onInitialize method then you are back to the problem
of
not being able to call getPage() in your components.
I think it is the opposite: if I create and add components in their
respective constructors I do not have access to getPage():
class MyPage {
MyPage() {
add(new MyPanel());
}
}
class MyPanel {
MyPanel() {
log.debug(getPage() = + getPage()); = null
add(new Label(id, getString(resKey)); = does not resolve
}
}
So at least in my panels and other containers I would keep creating
components in onInitialize(). Is that right?
Overridable factory methods in my base page (which should not be called
from
the constructor) are mainly there to create Components, so from where can
they be called if I can't override onInitialize()? I would not like to go
back to onBeforeRender and maintain a flag myself.
Cheers
Hans
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3298712.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
Re: final Page.onInitialize()
I don't believe the goal of onInitiallize is to move all component creation from the constructor to onInitialize, since if you are adding the component to the parent in the onInitialize method then you are back to the problem of not being able to call getPage() in your components. I say keep constructing components in constructors as well as adding them to their parents, and ONLY use onInitialize for initialization logic. The sort of stuff you'd put in onBeforeRender that would only run once. I'm not weighing in on changing Page's onInitialize from final, but I fear if users begin constructing and adding their components in the onInitialize call, then it removes the guarantee from that method that getPage() calls will always function correctly. -Clint On Wed, Feb 2, 2011 at 4:11 AM, Hans Lesmeister 2 hans.lesmeis...@lessy-software.de wrote: Hi, After onInitialize was introduced in 1.4.12 we have done a lot of refactoring in a lot of pages to get component-creation out of the constructors and into onInitialize. Especially calling overridable factory methods from a constructor is gone now which we and PMD really appreciate. Carl-Eric Menzel-7 wrote: I think this could be sufficiently guarded by putting a good explanation on onInitialize's javadoc. Besides, by this logic, Component is also incompletely initialized until the moment it gets added to the page. Ack +1 for Carl-Eric's patch Cheers Hans -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/final-Page-onInitialize-tp3250951p3253718.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [announce] Wicket 1.5-RC1 is released!
I believe the wicket-examples attached jetty jar was upgraded which required the servlet update. On Saturday, January 22, 2011, tetsuo ronald.tet...@gmail.com wrote: Er... why was servlet API dependency version upgraded to 2.5? I can't remember the discussion. Searched for it, but only found a pre-1.4 discussion, which was settled on 2.4. On Sat, Jan 22, 2011 at 7:02 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: The Wicket Team is proud to introduce the first Release Candidate in Wicket 1.5 series. The 1.5 series provides the following major improvements: * A more powerful and flexible request processing pipeline * Intercomponent event mechanism * Improved configuration * More flexible markup loading * Better proxy support (x-forwarded-for header) More detailed migration notes are available on our [Migrate to 1.5 Wiki Page](https://cwiki.apache.org/WICKET/migration-to-wicket-15.html) Release Artifacts: * Subversion tag: http://svn.apache.org/repos/asf/wicket/releases/wicket-1.5-RC1 * Changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC * To use in Maven: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.5-RC1/version /dependency * Download the full distribution: http://www.apache.org/dyn/closer.cgi/wicket/1.5-RC1 (including source) Cheers!
onError missing from SubmitLink
I made the following observation when working with a form today. When using an AjaxSubmitLink or AjaxButton you override the onSubmit and the onError methods. However normal non-ajax ones (SubmitLink and Button) have the onSubmit() method, but don't have the onError() method. Is that intentional? It didn't cause us any trouble since the Form's own onError() worked fine for us. I had just been surprised by the difference from between the ajax and normal component versions. -Clint
Re: Display component feedback message once: safety net renders them always before
I'd like to see it in core! On Thu, Jan 13, 2011 at 2:19 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jan 4, 2011 at 10:13 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I had encountered this issue and for one of my training classes, I threw together a solution. Your post prodded me to go ahead and post my solution as a blog post. After dusting off my long-forgotten blog, here it is: http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback -messages-that-arent-rendered-by-other-feedback-panels/ (or http://bit.ly/eHUEuN if that gets chopped up). Moving this discussion to dev@ - does anyone think that I should commit this catch all feedback panel to core? Would it be useful to others? I've used it, or something similar in several applications - not sure if others have had similar requirements. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Future hosting of wicket stuff
I don't know if I've any pull in voting, but +1 for github from me. It also would help in cases when a Wicket-Stuff idea may want to fork Wicket core to try new stuff. -Clint On Tue, Dec 14, 2010 at 10:39 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 for github biggest drag on managing wicketstuff is the high price for accepting/applying/submitting patches; at github it is almost non-existant since anyone can raise a pull request and they are trivial to apply. -igor On Tue, Dec 14, 2010 at 6:29 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Things change and while we had a nice stay at sf.net, I think it is time to move on with Wicket Stuff to newer ground. We have had this discussion before and the discussion stalled mostly because Apache and Google were in talks about a new service called Apache Extras [1]. Fortunately those talks are now over and we can continue our future of Wicket Stuff hosting discussion. In my opinion there are two possible hosting solutions for Wicket Stuff: - the newly announced Apache Extras - github's organization feature For Wicket Stuff we have a couple of things that worked fairly badly in the past. SVN connectivity from our build system connecting to SF.net was spotty at best, and didn't work most of the time. This has improved considerably by using Hudson instead of Teamcity (though not all builds that were done on teamcity have been migrated to hudson) I declare the JIRA instance of wicket stuff officially dead and gone to meet its maker. While we could opt for another JIRA enterprise license, I find maintaining the service a chore, and having to upgrade every now and then a waste of time better used to build cool stuff. While the issue trackers of Apache Extras (i.e. google code) and github are barebones, they have enough features to work with—we're not building missile guidance software requiring CMM level 5, SAS-71 etc certification. A similar issue arises with confluence. While I appreciate confluence being the best wiki available, again maintaining and upgrading it is no picnic, and both Apache Extras and github provide fine implementations of wikis. So I'd like to propose the following options: - stay at sf.net but use the sf.net hosted issue tracker and wikis - move everything over to an Apache Extras Wicket Stuff project - move everything over to a Github Wicket Stuff organization Staying at sf.net - scm options: SVN, Git, Mercurial, Bazaar, or CVS - no social options - No Apache Extras brand name - account management a drag - no limitation on allowed open source licenses - web UI a complete travesty Moving to Apache Extras - scm options: HG and SVN - no social options - Apache Extras brand name - account management a drag - limitation on allowed open source licenses Moving to Github - scm options: git - many social options (easy forking/merging/pull requests, etc) - No Apache Extras exposure - account management possibly easier (less need to actually add accounts to projects for sure) - no limitation on allowed open source licenses For this exercise I assumed the wiki and issue trackers of both github and Apache Extras are equally barebones. What do you think? If I've missed something add to this thread. If you prefer one solution over the other speak up! Martijn [1] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches
Re: overriding isVisible bad?
Yesterday a friend following this thread pointed out that we should rethink
our overriding of onVisible and use onConfigure. I've used
LoadabledDetachableModels to cache the value used in my isVisible/isEnabled
overriding so changing values mid request aren't a problem. That is its
whole purpose. Also calling .detach() on that model isn't hacky, that is its
design.
While I appreciate having onConfigure as an option it seems like overriding
isVisible is still the cleaner and clearer way. Folks just need to follow
the rule that expensive calls should be contained in an LDM.
Am I stuck in the past in holding this view?
-Clint
On Thu, Dec 2, 2010 at 4:03 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
What about using onconfigure to replace loadabledetachablemodel ? We
have had some trouble with loadabledetachablemodels when their state
is frozen before a dependent model has been initialized (for example)
and we need to call model.detach() from within our code, which seems
bit hacky.
Initializing also models at a specific known requestcycle moment might
be beneficial. Ofcourse it is not so straightforward as with
enable/visible state.
**
Martin
2010/12/1 Igor Vaynberg igor.vaynb...@gmail.com:
i would be happy if that was good enough. in the past it hasnt been,
thats why we have the current solution. maybe we can try it again in
1.5 and see what happens.
-igor
On Tue, Nov 30, 2010 at 11:44 AM, Pedro Santos pedros...@gmail.com
wrote:
I have a different point of view, the HTTP imposes us some limitations,
we
will hardly have an good synchronization between the component state on
browser and server using only HTTP conversation. So it is mandatory the
service layer to respect the described security restriction.
On Tue, Nov 30, 2010 at 5:32 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
an easy example is security.
a user views a page that allows them to delete another user
meanwhile their permissions are tweaked and they can no longer delete
other users
half an hour later the user clicks the delete button - this should
fail, but wont if we are using last-rendered state.
-igor
On Tue, Nov 30, 2010 at 11:18 AM, Pedro Santos pedros...@gmail.com
wrote:
I need to look better on which core components are relying on an
updated
visibility/enabled state at the process event time, and why the last
rendered state wouldn't be enough to them to work nicely.
On Tue, Nov 30, 2010 at 3:19 PM, Igor Vaynberg
igor.vaynb...@gmail.com
wrote:
currently we only invoke configure before the render. this would
mean
we would have to invoke it before processing a listener, clearing
the
cache, and then invoking it again before render. i wonder if that is
enough places to invoke it
-igor
On Tue, Nov 30, 2010 at 9:15 AM, Pedro Santos pedros...@gmail.com
wrote:
If user click an link, it will change the value of some property
at
the
process_event request cycle step. Then the processor will go to
the
respond
step, will invoke every component before render method which will
end
up
invoking the Component#configure and updating the
visibility/enabled
state
(even if it changes, we are able to work with the updated state).
So
when
the this component has the opportunity to render it self, it will
be
aware
its update state.
On Tue, Nov 30, 2010 at 2:39 PM, Igor Vaynberg
igor.vaynb...@gmail.com
wrote:
there are other places that should be checked though. for example
before we invoke a listener on the component we should check
again to
make sure that visibility hasnt changed. eg if visibility depends
on
some property of the user clicking the link that changed between
render and clicking the link.
-igor
On Tue, Nov 30, 2010 at 8:30 AM, Pedro Santos
pedros...@gmail.com
wrote:
An implementation idea:
Component {
public final void configure()
{
if (!getFlag(FLAG_CONFIGURED))
{
setVisible_NoClientCode(isVisible()); //we only
check
the
user
isVisible in here
onConfigure();
setFlag(FLAG_CONFIGURED, true);
}
}
}
On Tue, Nov 30, 2010 at 2:16 PM, Igor Vaynberg
igor.vaynb...@gmail.com
wrote:
so how is it different if they can still override something
that
needs
to be checked all the time?
-igor
On Tue, Nov 30, 2010 at 8:02 AM, Pedro Santos
pedros...@gmail.com
wrote:
I understand the concern about possible isVisible
implementations
like
isVisible(return currentlyTime 10:00:00;) //imagine this
component
being
rendered at 09:59:59
isVisible(return dao.list().size() 0);// performance
issues
But maybe we can have the best from both approaches. This is
an
Re: Request for input: resource loading search pattern flowchart
Jeremy, If possible you may try color coding the different sections of the file name: filename_variation_style_es_MX.xml That way as the pieces are removed the pattern will be obvious to the reader. Just be cautious in your color choices: you wouldn't want a double rainbow clear across your slide. -Clint On Wed, Sep 22, 2010 at 2:55 AM, Sven Meier s...@meiers.net wrote: Hi Jeremy, IMHO your chart misses two important points: - string resources from parental components take precedence, - Wicket mangles string resource keys, e.g. foo.bar.baz.Required bar.baz.Required baz.Required Regards Sven -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Request-for-input-resource-loading-search-pattern-flowchart-tp2549733p2549872.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Making Wicket Fully Compatible with Google App Engine
Thanks for all the responses. I've gone ahead and created https://issues.apache.org/jira/browse/WICKET-3064 to track the overall GAE Compatibility state. Currently to get Wicket to run on GAE the process is: 1) Make your project with Wicket 2) Google around grab some code trust it 3) Deploy to App Engine 4) Profit! (Kidding) My goal is to remove step 2. I'm not saying that Wicket should instantly work with GAE, but just that if it fails, that Wicket itself will help you get it up and running. (Helpful error messages, minor internal changes, etc.) Eclipse is telling me that there are 99 errors to fix. Just some initial tracking down looks like 1/3rd are file access items that shouldn't be changed in Wicket. A bunch of issues with the javax.swing.* and java.awt.* libraries. And a few other minor changes. The workspace where I'm trying to break Wicket on GAE is http://wicketexamples.appspot.com. Let me know if you want to view the logs and contribute. Regarding creating a separate project in Wicket-Stuff or a template, I'm open to those ideas, but the changes I'm mainly looking at couldn't be done in a separate project. Like Jeremy said: its time java.awt and java.swing were eliminated! -Clint Checketts
Making Wicket Fully Compatible with Google App Engine
There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Making Wicket Fully Compatible with Google App Engine
Sure I could take whichever approach the core team prefers. A bonus of having a master issue is once it gets resolved that the release notes will specifically mark that it is compatible with GAE. On Mon, Sep 20, 2010 at 7:52 AM, Peter Ertl pe...@gmx.org wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Wicket Example on GAE (Google App Engine) - Form post back
Ha ha. You make them sound like a sort of candy. Sorry to pull the newbie card. But any tips on how to create a patch? Unfortunately the page on the Wicket site is blank ( http://wicket.apache.org/contribute/patch.html) Maybe its written in Whitespace and I need a decoder ring. I'm guessing I can just checkout the code using subversion then use some command to generate a patch/diff. Any hints on the steps? Thanks, -Clint On Tue, Sep 14, 2010 at 11:06 PM, Jeremy Thomerson jer...@wickettraining.com wrote: jiras (with patches) are great! -- Jeremy Thomerson http://www.wickettraining.com
Re: Wicket Example on GAE (Google App Engine) - Form post back
Figures: it wasn't a form postback. Just needed to throw in a Model between the repeater and the List. Strange how it worked without the model locally, but broke once on GAE. Must be the clustering. Does it make sense for me to open up Jiras while improving the built-in wicket examples? Or is there some simpler, less nagging way? -Clint On Thu, Sep 9, 2010 at 6:16 AM, Clint Checketts checke...@gmail.com wrote: Yes. I forgot to mention that I am also using the proper HttpSessionStore and it still isn't doing the right post/redirect behavior. Still it makes me wonder if there is some glitch or something in the RequestCycle that GAE isn't handling right. -Clint On Thu, Sep 9, 2010 at 12:07 AM, Dominik Drzewiecki dominik.drzewie...@gmail.com wrote: You have overriden newSessionStore() in your application in order to use HttpSessionStore rather than the default SecondLevelCacheSessionStore, haven't you? Take a look at Dan's blog entry : http://www.danwalmsley.com/2009/04/08/apache-wicket-on-google-app-engine-for-java/ cheers, /dd -- /* Spelin donut mader if iz ina coment */
Re: Wicket Examples on Google App Engine: Usage of AWT and Swing
Jira: https://issues.apache.org/jira/browse/WICKET-3036 On Tue, Sep 7, 2010 at 12:08 PM, Peter Ertl pe...@gmx.org wrote: Could you file an JIRA issue on that? Am 07.09.2010 um 05:54 schrieb Clint Checketts: I've been playing around with Wicket on Google App Engine here and there and decided to try my hand at getting the Wicket Examples running on it. So here it is: http://wicketexamples.appspot.com/ I intend to add more to it little by little, but today is the first day I've actually had it uploaded. I had to disable a couple of the examples to get it to run. Google App Engine (aka GAE) disallows certain Java classes like filesystem access due to its cloud approach. They also locked down Java.AWT.*, Javax.Swing.*. It makes sense: its for writing webapps, not desktop clients. So, I understand it's good to re-use existing code, but in the case of TreeModel and Color constants, can Wicket move away from them to its own versions? (Let's keep the discussion focused on the low hanging fruit like constants and TreeModels for now, I'll save other stuff like Dimension, Stroke, and other Graphics2D stuff for another thread.) Thanks, -Clint Checketts
Re: [vote] release wicket 1.4.11
Where can I find out how this voting works? Who can vote? What is a binding/non-binding vote? Thanks, -Clint On Mon, Sep 6, 2010 at 6:54 AM, jcgarciam jcgarc...@gmail.com wrote: [X] Yes, release On Mon, Sep 6, 2010 at 5:03 AM, Jan Kriesten [via Apache Wicket] ml-node+2528023-1530337920-65...@n4.nabble.comml-node%2b2528023-1530337920-65...@n4.nabble.com ml-node%2b2528023-1530337920-65...@n4.nabble.comml-node%252b2528023-1530337920-65...@n4.nabble.com wrote: [X] Yes, release Best regards, --- Jan. -- View message @ http://apache-wicket.1842946.n4.nabble.com/vote-release-wicket-1-4-11-tp2527078p2528023.html To unsubscribe from Apache Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY= . -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-release-wicket-1-4-11-tp2527078p2528260.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Wicket Examples on Google App Engine: Usage of AWT and Swing
I've been playing around with Wicket on Google App Engine here and there and decided to try my hand at getting the Wicket Examples running on it. So here it is: http://wicketexamples.appspot.com/ I intend to add more to it little by little, but today is the first day I've actually had it uploaded. I had to disable a couple of the examples to get it to run. Google App Engine (aka GAE) disallows certain Java classes like filesystem access due to its cloud approach. They also locked down Java.AWT.*, Javax.Swing.*. It makes sense: its for writing webapps, not desktop clients. So, I understand it's good to re-use existing code, but in the case of TreeModel and Color constants, can Wicket move away from them to its own versions? (Let's keep the discussion focused on the low hanging fruit like constants and TreeModels for now, I'll save other stuff like Dimension, Stroke, and other Graphics2D stuff for another thread.) Thanks, -Clint Checketts
