Re: embed Wicket application on any page
Thank you for the great answer! I'll have to think about our options. And probably read that interesting book. -Sampo Sent: Friday, October 07, 2016 at 9:55 AM From: "Martin Grigorov" <mgrigo...@apache.org> To: "users@wicket.apache.org" <users@wicket.apache.org> Subject: Re: embed Wicket application on any page Hi, You are forgetting that: 1) A Page produces a .. You cannot put this into a . 2) The Ajax urls are relative, i.e. they will be resolved against the wrapping page, not against the embedded thingy. 3) Assuming that you produce just document fragments, i.e. render components instead of pages and put them in a , then they will most probably depend on some CSS and/or JS resources. Those resources won't be available unless you take special care to contribute them within the component's markup. 4) Once you fix the CSS contribution it will be quite easy to break the layout of the wrapping page. You may need to use Shadow DOM to prevent this. https://manning.com/books/third-party-javascript - this book explains many of the problems one will face when embedding in others web sites/apps. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov[https://twitter.com/mtgrigorov] On Fri, Oct 7, 2016 at 6:16 AM, samket <sam...@gmx.com> wrote: > My employer doesn't like iframes. It might be an issue to our customers > too. Am I making things too difficult for myself by trying to use Wicket > for this? Am I forgetting something vital? I'd like to hear opinions. > > -Sampo > > > > Sent: Thursday, October 06, 2016 at 10:15 PM > From: "Ernesto Reinaldo Barreiro" <reier...@gmail.com> > To: "users@wicket.apache.org" <users@wicket.apache.org> > Subject: Re: embed Wicket application on any page > Use an iframe? > > On Thu, Oct 6, 2016 at 8:14 PM, samket <sam...@gmx.com> wrote: > > > Hi, > > > > Is it possible to embed a Wicket application on any page? A bit like > > Google Map. Lets say there is a div element on an arbitrary page and I > use > > javascript to bring the Wicket application's front page inside that div. > > Naturally, I would make sure that the application uses AJAX for > everything > > so that the browser's page does not change. Are there any difficulties in > > this approach? I can imagine session expiration might cause difficulties. > > The default session expired page causes a page reload which is unwanted. > > > > -Sampo > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > -- > Regards - Ernesto Reinaldo Barreiro > > - > 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: embed Wicket application on any page
My employer doesn't like iframes. It might be an issue to our customers too. Am I making things too difficult for myself by trying to use Wicket for this? Am I forgetting something vital? I'd like to hear opinions. -Sampo Sent: Thursday, October 06, 2016 at 10:15 PM From: "Ernesto Reinaldo Barreiro" <reier...@gmail.com> To: "users@wicket.apache.org" <users@wicket.apache.org> Subject: Re: embed Wicket application on any page Use an iframe? On Thu, Oct 6, 2016 at 8:14 PM, samket <sam...@gmx.com> wrote: > Hi, > > Is it possible to embed a Wicket application on any page? A bit like > Google Map. Lets say there is a div element on an arbitrary page and I use > javascript to bring the Wicket application's front page inside that div. > Naturally, I would make sure that the application uses AJAX for everything > so that the browser's page does not change. Are there any difficulties in > this approach? I can imagine session expiration might cause difficulties. > The default session expired page causes a page reload which is unwanted. > > -Sampo > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
embed Wicket application on any page
Hi, Is it possible to embed a Wicket application on any page? A bit like Google Map. Lets say there is a div element on an arbitrary page and I use javascript to bring the Wicket application's front page inside that div. Naturally, I would make sure that the application uses AJAX for everything so that the browser's page does not change. Are there any difficulties in this approach? I can imagine session expiration might cause difficulties. The default session expired page causes a page reload which is unwanted. -Sampo - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and ExtJS
I would make class MyMenu as a Behavior or possibly a Label and class SubMenu
as a POJO (don't make it extend Component). Everything doesn't have to be a
subclass of component, right? You need to code MyMenu in such way that it
generates javascript from POJOs. That way your developers don't need to add
unnecessary elements to markup. MyMenu would be suitable as a behavior because
it's just javascript and doesn't need html elements. You would simply add the
behavior to the page. It could be a Label as well. I'm not sure which approach
has more benefits.
For the URLs that wicket must generate for you, see RequestCycle.urlFor()
methods. For example, there's the urlFor(Class, PageParameters) method that
creates a link to a page. To invoke some method on some component you would use
urlFor(component, ILinkListener.INTERFACE) and the component must implement the
ILinkListener interface.
- Original Message -
From: Brian Mulholland
Sent: 10/24/11 05:41 PM
To: users@wicket.apache.org
Subject: Re: Wicket and ExtJS
First, thanks for the prompt response. Okay, so I am struggling with writing a
menu component. I saw the Suckerfish menu example and tried to adapt that
towards my needs. I want my fellow developers to be able to write something
like: MyMenu topMenu = new MyMenu(topMenu); MyMenu subMenu1 = new
SubMenu(subMenu1, Here is a submenu); MyMenu subMenu2 = new
SubMenu2(subMenu2, Here is another submenu); subMenu1.addMenuItem(new
BookmarkableLink(LINK_ID, SomePage.class), Some Page);
subMenu2.addMenuItem(new BookmarkableLink(LINK_ID, SomeOtherPage.class), Some
Other Page); submenu1.addMenuItem(new MyMenuSeparator());
subMenu1.addMenuItem(new Link(LINK_ID) { public void onClick() { //do something
} }, An action); subMenu1.addMenuItem(new MyClientSideAction(Do Local Work,
some javascript code or the name of a client side function to invoke or
something)); subMenu2.addMenuItem(new Link(LINK_ID) { public void onClick() {
//do something else } }, Another action); sub
Menu2.addMenuItem(new MyClientSideAction(Other Local Work, some javascript
code or the name of a client side function to invoke or something)); Which
would then generate Ext code. Either as one large block using the Ext JSON
config objects (if you've ever seen Ext code you know what I mean), or
generating a series of smaller scriptlets each generating the indiidual item
needed and adding by name to the component that is it's parent. The former
might look like this (m just typing this now so forgive any typoes).
Ext.onReady(function() { //some code to make parent components not shown until
we get to it's items array which might look like: items: [{ xtype: 'menu',
items: [{ xtype: 'menu', text: 'Here is a submenu', items: [{ xtype:
'menuitem', text: 'Some Page', handler: { //some magic code that somehow gets
the wicket link to forward to Some Page } }, { xtype: 'separator' }, { xtype:
'menuitem', text: 'An Action', handler: { //some magic code that somehow
invokes the onC
lick method on the server in the right link } }, { xtype: 'menuitem', text:
'Do Local Work', handler: { //the code or function provided } }] //end first
submenu's items }, { xtype: 'menu', text: 'Here is another submenu', items: [{
xtype: 'menuitem', text: 'Some Other Page', handler: { //some magic code that
somehow gets the wicket link to forward to Some Other Page } }, { xtype:
'menuitem', text: 'Another Action', handler: { //some magic code that somehow
invokes the onClick method on the server in the right link } }, { xtype:
'menuitem', text: 'Other Local Work', handler: { //the code or function
provided } }] //end secondsubmenu's items }] //end topMenu's items }] //end the
parent object (whatever that is) items }); the second proposal might have
independent script tags at each wicket:id tag, replacing the element with a
script tag that gets the parent (as detected by the parent hierarchy in wicket)
and adds the component to it's parent. Because Ext stores each function a
nd executes it in order, it should have the same effect as above, but allow
the component to be more independent. It only needs to detect it's parent. I
like this style better, but I have less idea how to implement it through
wicket. How can I override what wicket writes for it's body? So I would end up
with many small block like the following throughout my rendered markup.
SCRIPT Ext.onReady(function(){ var parent = Ext.getCmp(myParent);
parent.add(Ext.create(whatever we are creating, { //the config parms }); });
/SCRIPT Since I don't know how to do that, I have been writing towards the
first example. the result of my stumblings is a set of components that all
implement an interface that asks for the snippet of the first example that
represents their contribution, and then adds it as a header contribution to the
page. Links are resolved by css styling the markup wicket generates as
display:none, and then using javascript to pick up the link
Re: Wicket + BIRT Report Integration
I haven't done BIRT integration in years but I can point to some references. This is the official integration guide: http://www.eclipse.org/birt/phoenix/deploy/ I know of two ways to integrate: by using the report viewer and by creating a servlet. As far as I know the report viewer is actually a sample application that you can use as a starting point for your own development. See this guide for the viewer: http://www.eclipse.org/birt/phoenix/deploy/viewerSetup.php If you decide to create a servlet, you'll need to learn the engine API but you'll have more control over everything. See this guide for the engine API: http://www.eclipse.org/birt/phoenix/deploy/reportEngineAPI.php - Original Message - From: sakthi vel Sent: 10/22/11 09:45 AM To: users@wicket.apache.org Subject: Wicket + BIRT Report Integration Hi All, Could anyone tell how to integrate the BIRT reports in wicket. Examples or references would of great help.
Re: DateField with String model
DateField seems to require a Date model. You can implement a model (a class
that implements IModel) that transforms between String and Date.
public class DateModel implements IModelDate {
private static final long serialVersionUID = 1L;
private final IModelMyBean innerModel;
public DateModel(IModelMyBean innerModel) {
this.innerModel = innerModel;
}
public void detach() {
innerModel.detach();
}
public Date getObject() {
String value = innerModel.getObject().getDate();
if (value == null) {
return null;
}
return MyDateConverter.asDate(value);
}
public void setObject(Date object) {
String value;
if (object != null) {
value = MyDateConverter.asString(object);
} else {
value = null;
}
innerModel.getObject().setDate(value);
}
}
- Original Message -
From: Pirlouit Le
Sent: 10/07/11 11:38 AM
To: users@wicket.apache.org
Subject: DateField with String model
Hi wicket community,I'm trying to use a DateField
(org.apache.wicket.extention.yui.calendar.DateField)with a String in the model,
is this possible, perhaps can I provide a converter, a smth like this ?
Kind Regards,
Benoît de Biolley
-
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?
Knowing what my co-workers are like, these are the most important things that I say to them. So this list is directed towards them in particular. 1. When receiving parameters in a constructor or method, a model (an instance of IModel) is almost always the right choice instead of a raw model object. Almost everyone here has mentioned this rule in different words (probably most better than mine). 2. Apply your generic object-oriented programming skills to web page programming. When dealing with pages and panels, know when to use inheritance and when not to. Inheritance is something you should usually try to avoid and use composition instead. Inheritance might save you a couple lines of code but it tends to make the code crazy difficult to understand. Having said that, it must be mentioned that there are plenty of situations where using inheritance is justified. I just think the cost of using inheritance in the wrong place is so high that it deserves to be feared. 3. A page's markup must be kept very clean. It should never be no more than 50 lines, or so. Use panels to separate parts of the page. A (positive) result of this is that the page's java file is probably clean too. The main reason for this rule is that it should always be easy for everyone to get an idea of the general structure of a page. 4. When a markup contains a wicket:id, the corresponding java file should probably contain a corresponding add-method invocation. I.e. the corresponding add-method invocation shouldn't be located in some other (unrelated) java file. For understandability's sakes. 5. Don't be afraid to refactor source codes. Even those that were originally made by someone else. There are plenty of reasons why this is important. One of them is that nobody makes perfect code the first time. You shouldn't even try to make perfect code the first time. It's usually fine if you make monolithic panels (not pages), use plenty of inner classes and make inefficient code. They will be refactored later if they are modified often and if people adhere to this rule. 6. With Wicket as the web application framework you rarely if ever need to create servlets. File downloading is possible with resources and it's possible to create bootstraps too. Okay, this rule doesn't deserve to be in the top 10, but I seriously don't want to see more servlets being made - EVER! :) 7. It's pretty important to learn about all the different types of models. They may be a little more difficult concept to understand than components. 8. WebMarkupContainer is a simple yet useful component that does nothing unless you program it do something. WebComponent is equally simple but less often useful because it can't be a parent to other components. - Original Message - From: Jeremy Thomerson Sent: 07/28/11 01:29 AM To: users@wicket.apache.org Subject: RFC: Ten things every Wicket programmer must know? 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? Please reply back if you have input. Please note that by replying, you are granting me full permission to use your response as part of my article without any attribution or payment. If you disagree with those terms, please respond anyway but in your response mention your own terms. Best regards, -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice on i18n
Hi In the company I work in we always put resources in one file per language. I don't see much problems maintaining it, except if we had reusable components that were shared across applications. In reusable components' case it would seem a very good idea. Actually, once a customer specifically requested that resources are in one single file because it would make them easier for them to review and edit. I also like the fact that I don't have to think about which file to put each message in. -s - Original Message - From: Christian Grobmeier Sent: 01/29/11 10:03 AM To: users@wicket.apache.org Subject: Best practice on i18n Hello, I have read and understand about i18n but I am curious about best practices. Is it really a good option to have several language files per component? F.e. my form component needs i18n, so does my page which holds the form alone. Wicket does of course not search in the i18n files for the page. I have the option to put all i18n in one file (which is ok for the moment but will be worse later) or to add 4 language files. Another alternative is to build up a custom IStringResourceLoader which loads the list from the database. This seems the best option to me from maintenance aspects. Any comments appreciated :-) Best regards, Christian - 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: Are there any cases when I can rearrange component tree?
If you have markup like this: div wicket:id=c/div You can put any panel (named c) in using the add-method and later switch it to any panel (named c) using the replace-method. You could create lots of tiny reusable panels and compose them into various structures. In my mind, Wicket is just as flexible as desktop programming because markup is limiting only where you want it to be limiting. When a panel needs lots of flexibility it tends to be small and when it doesn't it tends to be large. - Original Message - From: Dmitry Grigoriev Sent: 11/10/10 05:41 AM To: users@wicket.apache.org Subject: Are there any cases when I can rearrange component tree? Hello all,I'm new to Wicket. Just wonder about subj (theoretical interest). On onehand, stateful component model has no architectural limitations on itsown preventing me from reattaching component to different parent, justlike I can do with desktop applications or with any self-contained treestructure. On another hand, Wicket's component tree structure is boundto hard-coded markup, making such change-of-parent impossible.Is thereany opportunity to do this? (No matter how sophisticated.)The reason for my interest is that I'm collecting ideas for statelesscomponents support in my web framework. Stateless component hierarchywould likely be immutable (hard-coded into application logic rather thanstate) which looks like a significant limitation at first sight,compared to do-anything-you-want desktop programming. But I don't yethave much experience with web component frameworks and don't know isthis limitation really annoying or not. For now it seems to me thatWicket has this lim itation too but does not suffer a lot from it. Am Iright?Thanks.-- Cheers,dimgel-To unsubscribe, e-mail: users-unsubscr...@wicket.apache.orgfor 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
We need to wait until all components are added so that we can arrange
them into correct hireracy before rendering.
May I suggest that components are added with help of a builder object, for
example:
public MyPanel(String id) {
super(id);
Builder b = new Builder(this); // the Builder gets reference to this MyPanel
b.add(new TextField(name)); // can be child of form which is added later
b.add(new SomeForm(form));
b.build(); // after this line this MyPanel contains the components name and form
}
If MyPanel's super class needs to access the same builder, it can provide a
constructor for it. In that case b.build() should be only invoked in MyPanel's
constructor.
If a developer uses more than one builder in a constructor, he can restrict
moving of components in markup to some extent:
public MyPanel(String id) {
super(id);
Builder b1 = new Builder(this);
b1.add(new TextField(name)); // in markup, name can't be put under form
because it's in a different builder
b1.build();
Builder b2 = new Builder(this);
b2.add(new SomeForm(form);
b2.build();
}
Of course this doesn't solve the problem Igor mentioned. For that you'd need
the old-fashioned way:
public MyPanel(String id) {
super(id);
SomeForm form = new SomeForm(form);
form.add(new TextField(name); // in markup, name can't be moved out from
form
add(form);
}
Developers would need to mix different approaches for building hierarchies if
security is an issue. On second thought, I should use a broader term than
security because there is more than one reason to restrict those pesky
designers ;)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
