.
>
> Then I set visible(true) during runtime and at the component to the
> AjaxTarget.
>
> The component is not rendered.
>
> Is there a way to get this to work?
>
Add the parent component that contains the wicket:enclosure markup to the
AjaxRequestTarget.
You should not recreate the TreeModel and for most cases DefaultTreeModel is
what you want. If you are adding a node, add it with:
http://java.sun.com/javase/6/docs/api/javax/swing/tree/DefaultTreeModel.html#insertNodeInto(javax.swing.tree.MutableTreeNode,%20javax.swing.tree.MutableTreeNode,%20int
add tree.updateTree(target) before adding the tree to the target.
hth,
jim
>
> tree.addTreeListener(new TreeListener() {
>
>@Override
>public void onActivityClicked(String nameOfNode,AjaxRequestTarget
>target){
>
Have a look at Springs
WebApplicationContextUtils.getWebApplicationContext(...). This in
conjunction with org.springframework.web.context.ContextLoaderListener
should give you what you need.
best,
jim
On Wed, Apr 9, 2008 at 12:41 PM, Pinger <[EMAIL PROTECTED]> wrote:
>
> So I am using wicket an
+1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>
> velocityPropertiesFolder
> WEB-INF/classes
>
>
> velocity.properties
> velocity.properties
>
> 2
>
>
>
>
> James McLaughlin-3 wrote:
> >
> >
ull path to the template you are parsing,
the classpath loader will pick it up. Hope this helps, fattymelt.
>
>
> James McLaughlin-3 wrote:
> >
> > fattymelt,
> > It used to work that you could jar up your templates and put them
> > under WEB-INF/lib. If that d
fattymelt,
It used to work that you could jar up your templates and put them
under WEB-INF/lib. If that doesn't work, create your own
velocity.properties file and define the init-params
velocityPropertiesFolder and velocity.properties in your web.xml. You
can define there which loaders to use and w
> Looking ahead, I can imagine that as Wicket becomes ever more popular, there
> will be many organisations who will see it as a big plus that there are
> well-respected developers building, selling and maintaining well engineered,
> reliable and high-quality components with interesting features th
Hi Doug,
We definitely don't want to require users to strip wicket tags, if
that still needs to be done. I think we did that just to get it
working. I thought setRenderBodyOnly was enough, but if we still have
issues we should add in a MarkupFilter or use a Transformer. If menu2
only works with str
A quickstart attached to jira would be most appreciated.
http://wicketstuff.org/jira/browse/WSYUI.
Yui menu's distaste for wicket tags has been a long standing issue. To
get around it at first, we did
tMarkupSettings().setStripWicketTags(true). But then I thought that
was changed to calling setRen
rik rik,
you don't need to include the yui libraries. YuiMenuBar will do that
automatically. Remove them from your html and everything should work
fine.
best,
jim
On Nov 30, 2007 3:58 AM, rik rik <[EMAIL PROTECTED]> wrote:
> Hi to all,
> I've downloaded the sources of menu2 from svn, but I'm not
Hi Doug,
It is hard to say without knowing more about your app. As a rule, I
never keep references to data in my components. Components have only
refs to services (injectable) and all the data are encapsulated by
IModels of one sort or another. The IModels always implement
IDetachable and keep onl
On 10/18/07, Doug Leeper <[EMAIL PROTECTED]> wrote:
>
> I am using 1.3 (Trunk).
>
> I am calling AjaxRequestTarget.target.appendJavascript() right after i call
> AjaxRequestTarget.target.addComponent(). Is this the right approach?
>
> Do I have access to IHeaderResponse in an Ajax call?
Have your
Hi Doug,
You need to set up the TreeState when the tree first renders. You can
do this by overriding newTreeState.
Below is a snippet that shows one way of accomplishing this:
@Override
protected ITreeState newTreeState()
{
ITreeState state = new DefaultTreeState();
s
On 9/27/07, Doug Leeper <[EMAIL PROTECTED]> wrote:
>
> Has anyone been able to create a context menu for items on a LinkTree?
>
> If so, was it all JS based (like YUI)? or did you create a small framework
> to be used in Wicket?
>
> If the latter, would it be possible to contribute to the wicket-co
On 9/24/07, Mattijs Hoitink <[EMAIL PROTECTED]> wrote:
> hi all,
>
> i just checked out wicket-contrib-yui and wicket-contrib-yui-examples
> to do some testing.
> When i ran maven on it, the projects wouldn't build because of some
> wrong dependencies in the pom.xml.
> In a lot of places reference
Hi,
Hacking away at some tests, I figured the proper way to test an
AjaxSubmitLink would have been as follows:
Panel p = tester.startPanel(EventPanel.class);
FormTester ft = tester.newFormTester(p.getId() + ":eventForm");
ft.setValue("messageField", ALARM_MESSAGE);
>
> IMHO hardwiring is somehow an antipattern for me - maybe we could have a
> "setYuiPath" in it that defaults to the delivered YUI but leaves the
> possibility to have other YUI versions as well?
>
Well, its not really hardwired, its just a default fallback used by
the static factory methods.
On 8/28/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> Hi James,
>
> i checked out of svn today and changed yui to 2.3.0 - at first, all
> seemed ok, but when looking closer its a bit irritating.
No doubt. Exactly why I have procrastinated on this for the past month.
>
> In 2.2 you seem to have
> Also note that we did something similar in wicket-datetime. Maybe, in
> some future, it would be great to have all the YUI components
> together. For now, we could look whether the projects can at least be
> used together without having them bite. A thread of two weeks ago
> discussed this. The c
Yes there is. I haven't had much time to see what the impact of the
change would be, but I set up YuiHeaderContributor to be able to
select versions. If you have the time and inclination, you can setup
the 2.3.0 library under org/wicketstuff/yui/inc, and include the
library with something like this
I have a functional base for this already in wicket-contrib-yui trunk.
Needs a friendlier api and a bit of polish, but all the pieces are
there. I've been very short on time, so if anyone feels like picking
it up that would be great.
On 8/10/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Nope.
I actually have a rough version of yui menu done in
wicket-contrib-yui. It needs to be polished up quite a bit, which I
have been intending on doing for about 5 months now. It works with yui
2.2.2 with the exception that you must strip wicket tags or else the
yui menu parser barfs.
Any help moving
Hi Doug,
First I would make sure your TreeNode implementation creates children
lazily. You probably should only create children when children() is
actually called and provide logic for isLeaf and getChildCount() that
don't require creating the children.
You can create the initial state for the tre
t;
>public class XTreeModel extends javax.swing.tree.DefaultTreeModel
>
> Should my class, XTreeModel, implement IDetachable?
>
> Sean
>
>
> On 8/1/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
> >
> > For the trees in 1.3 (I haven't used 1.2.x in a
For the trees in 1.3 (I haven't used 1.2.x in a long time), if your
TreeNodes implement IDetachable, they wil be detached when the
requestcycle completes. Then it is up to you to implement some logic
in the methods you call to retrieve the user object (such as
getUserObject()) from the TreeNode to
27 matches
Mail list logo
