odlabs.wiquery
Hi list This question might be slightly off-topic. My apologies for this. I am trying to freshen up a project I was working on a few years ago. Back then I used org.odlabs.wiquery for several UI elements. In the meantime odlabs seems to not have upgraded that library and some forks appeared. No fork really looks like the up-to-date no-brainer replacement. What would be a sensible upgrade path or replacement? Thanks for your suggestions. Regards, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: component.isAuto - was: Wicket 1.5: The component(s) below failed to render (revisited)
Hi Martin, hi list
I guess I narrowed things down a bit. I was obviously looking at the
wrong places. The problem is with the renderedComponents Set (and not
with the isAuto flag as thought at first).
In the Page class there is that check here:
> // If component never rendered
> if (renderedComponents == null ||
> !renderedComponents.contains(component))
and this method:
> public final void componentRendered(final Component component)
> {
> // Inform the page that this component rendered
> if (getApplication().getDebugSettings().getComponentUseCheck())
> {
This method is obviously only run in the debug mode when the
ComponentUseCheck is activated (which is by default). Which also means
that said Set is only instantiated when ComponentUseCheck is activated.
Which also means the check in the first copy above will not be run when
ComponentUseCheck is false/deactivated.
Now that I deactivated that check, my renderer works again.
So there must be some problem with dynamic components. I looked through
the render methods of 1.5x and 1.4x. While some things changed, the flow
seems to be mostly the same. Nothing obvious.
I'd love to do a minimal quickstart but that won't be very minimal. I'd
have to add most of the renderer, or rewrite parts. I'll see if I find
some time to put together something small.
In the meantime. If somebody has an idea where to look at, I'd be happy
to test things out on my codebase.
Cheers,
Adrian
On 4/12/12 5:02 PM, Martin Grigorov wrote:
Hi,
On Thu, Apr 12, 2012 at 5:48 PM, Adrian Wiesmann wrote:
Hi
Me again with a follow up to my isAuto() problem.
Setting component.setAuto(true) is quite bad, since Wicket will remove all
components in the detachChildren() method which have the Auto Flag and which
are not an instance of InlineEnclosure. Which all of my components obviously
are not...
While the isAuto(true) results in a nicely rendered component tree, when you
try to click on - say a row in a list - then Wicket throws an error because
the component in question was removed.
Well here we are again. How can I port my renderer which adds components to
the component tree on the fly as I was able to do in Wicket< 1.5? What was
the intention to change the behaviour there?
It is not clear to me which behavior exactly has changed and now
causes you troubles.
Create a minimal quickstart that works on 1.4 and attach it to a ticket in Jira.
Regards,
Adrian
On 2/12/12 7:27 PM, Adrian Wiesmann wrote:
Hello list
Some while ago I posted a few messages to this list where I asked for
help in finding a problem with Wicket 1.5. I was not able to find the
bug back then. Now I downloaded the bleeding edge version 1.5.4 and
tried again. And now I am a step further.
I have that rendering engine where I take an XML file, build an object
tree from that and have a renderer rendering a Wicket object tree and
finally Wicket which renders the HTML UI from that.
Now I noticed with version 1.5 of Wicket, that this line in the
org.apache.wicket.Page.class are the key to my problem (lines 611, 612):
// If not an auto component ...
if (!component.isAuto()&& component.isVisibleInHierarchy())
I noticed that many of my components I add in my renderer on the fly are
returning isAuto = false on that line (and of course they are visible,
which adds them to unrenderedComponents and ultimately provokes the
error).
I then added this.setAuto(true); in one of my components. And voila, it
was not in the list of components which failed to render.
So here are my questions:
- What did change from version 1.4.x to version 1.5.x that results in
this error?
- Is that a bug in Wicket or do I need to fix my renderer somehow?
- What side effects does it have if I just add a setAuto(true) to all of
my components?
Thanks for your help!
Cheers,
Adrian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: component.isAuto - was: Wicket 1.5: The component(s) below failed to render (revisited)
Hi Me again with a follow up to my isAuto() problem. Setting component.setAuto(true) is quite bad, since Wicket will remove all components in the detachChildren() method which have the Auto Flag and which are not an instance of InlineEnclosure. Which all of my components obviously are not... While the isAuto(true) results in a nicely rendered component tree, when you try to click on - say a row in a list - then Wicket throws an error because the component in question was removed. Well here we are again. How can I port my renderer which adds components to the component tree on the fly as I was able to do in Wicket < 1.5? What was the intention to change the behaviour there? Regards, Adrian On 2/12/12 7:27 PM, Adrian Wiesmann wrote: Hello list Some while ago I posted a few messages to this list where I asked for help in finding a problem with Wicket 1.5. I was not able to find the bug back then. Now I downloaded the bleeding edge version 1.5.4 and tried again. And now I am a step further. I have that rendering engine where I take an XML file, build an object tree from that and have a renderer rendering a Wicket object tree and finally Wicket which renders the HTML UI from that. Now I noticed with version 1.5 of Wicket, that this line in the org.apache.wicket.Page.class are the key to my problem (lines 611, 612): // If not an auto component ... if (!component.isAuto() && component.isVisibleInHierarchy()) I noticed that many of my components I add in my renderer on the fly are returning isAuto = false on that line (and of course they are visible, which adds them to unrenderedComponents and ultimately provokes the error). I then added this.setAuto(true); in one of my components. And voila, it was not in the list of components which failed to render. So here are my questions: - What did change from version 1.4.x to version 1.5.x that results in this error? - Is that a bug in Wicket or do I need to fix my renderer somehow? - What side effects does it have if I just add a setAuto(true) to all of my components? Thanks for your help! Cheers, Adrian - 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
component.isAuto - was: Wicket 1.5: The component(s) below failed to render (revisited)
Hello list Some while ago I posted a few messages to this list where I asked for help in finding a problem with Wicket 1.5. I was not able to find the bug back then. Now I downloaded the bleeding edge version 1.5.4 and tried again. And now I am a step further. I have that rendering engine where I take an XML file, build an object tree from that and have a renderer rendering a Wicket object tree and finally Wicket which renders the HTML UI from that. Now I noticed with version 1.5 of Wicket, that this line in the org.apache.wicket.Page.class are the key to my problem (lines 611, 612): // If not an auto component ... if (!component.isAuto() && component.isVisibleInHierarchy()) I noticed that many of my components I add in my renderer on the fly are returning isAuto = false on that line (and of course they are visible, which adds them to unrenderedComponents and ultimately provokes the error). I then added this.setAuto(true); in one of my components. And voila, it was not in the list of components which failed to render. So here are my questions: - What did change from version 1.4.x to version 1.5.x that results in this error? - Is that a bug in Wicket or do I need to fix my renderer somehow? - What side effects does it have if I just add a setAuto(true) to all of my components? Thanks for your help! Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5: The component(s) below failed to render
On 12/21/11 11:46 AM, Per Newgro wrote: Do you use a border? Because border component assignment changed No borders. Mostly iterators and "plain" panels... Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5: The component(s) below failed to render
On 12/21/11 11:23 AM, Martin Grigorov wrote: All this looks OK. Can you paste the ids of the components which cannot be rendered ? You mean this? 1. [Component id = caption] 2. [RepeatingView [Component id = toolbars]] 3. [GWListActionToolbar [Component id = 0]] 4. [AjaxFallbackHeadersToolbar [Component id = 1]] 5. [RepeatingView [Component id = headers]] 6. [AbstractItem [Component id = 1]] 7. [ [Component id = header]] 8. [BorderBodyContainer [Component id = header_body]] 9. [Component id = label] 10. [ [Component id = orderByLink]] 11. [BorderBodyContainer [Component id = header_body]] 12. [Component id = label] 13. [AbstractItem [Component id = 2]] 14. [ [Component id = header]] 15. [BorderBodyContainer [Component id = header_body]] 16. [Component id = label] 17. [ [Component id = orderByLink]] 18. [BorderBodyContainer [Component id = header_body]] 19. [Component id = label] 20. [AbstractItem [Component id = 3]] 21. [ [Component id = header]] 22. [BorderBodyContainer [Component id = header_body]] 23. [Component id = label] 24. [ [Component id = orderByLink]] 25. [BorderBodyContainer [Component id = header_body]] 26. [Component id = label] 27. [AbstractItem [Component id = 4]] 28. [ [Component id = header]] 29. [BorderBodyContainer [Component id = header_body]] 30. [Component id = label] 31. [ [Component id = orderByLink]] 32. [BorderBodyContainer [Component id = header_body]] 33. [Component id = label] 34. [AbstractItem [Component id = 5]] 35. [ [Component id = header]] 36. [BorderBodyContainer [Component id = header_body]] 37. [Component id = label] 38. [ [Component id = orderByLink]] 39. [BorderBodyContainer [Component id = header_body]] 40. [Component id = label] 41. [GWListFilterToolbar [Component id = 2]] 42. [FilterForm [Component id = filterform]] 43. [RepeatingView [Component id = filters]] 44. [WebMarkupContainer [Component id = 1]] 45. [TextFilterEx [Component id = filter]] 46. [TextField [Component id = filter]] 47. [WebMarkupContainer [Component id = 2]] 48. [ChoiceFilter [Component id = filter]] 49. [DropDownChoice [Component id = filter]] 50. [WebMarkupContainer [Component id = 3]] 51. [TextFilterEx [Component id = filter]] 52. [TextField [Component id = filter]] 53. [WebMarkupContainer [Component id = 4]] 54. [NoFilter [Component id = filter]] 55. [WebMarkupContainer [Component id = 5]] 56. [NoFilter [Component id = filter]] 57. [Component id = caption] 58. [RepeatingView [Component id = toolbars]] 59. [GWListActionToolbar [Component id = 5]] 60. [AjaxFallbackHeadersToolbar [Component id = 6]] 61. [RepeatingView [Component id = headers]] 62. [AbstractItem [Component id = 1]] 63. [ [Component id = header]] 64. [BorderBodyContainer [Component id = header_body]] 65. [Component id = label] 66. [ [Component id = orderByLink]] 67. [BorderBodyContainer [Component id = header_body]] 68. [Component id = label] 69. [AbstractItem [Component id = 2]] 70. [ [Component id = header]] 71. [BorderBodyContainer [Component id = header_body]] 72. [Component id = label] 73. [ [Component id = orderByLink]] 74. [BorderBodyContainer [Component id = header_body]] 75. [Component id = label] 76. [AbstractItem [Component id = 3]] 77. [ [Component id = header]] 78. [BorderBodyContainer [Component id = header_body]] 79. [Component id = label] 80. [ [Component id = orderByLink]] 81. [BorderBodyContainer [Component id = header_body]] 82. [Component id = label] 83. [AbstractItem [Component id = 4]] 84. [ [Component id = header]] 85. [BorderBodyContainer [Component id = header_body]] 86. [Component id = label] 87. [ [Component id = orderByLink]] 88. [BorderBodyContainer [Component id = header_body]] 89. [Component id = label] 90. [GWListFilterToolbar [Component id = 7]] 91. [FilterForm [Component id = filterform]] 92. [RepeatingView [Component id = filters]] 93. [WebMarkupContainer [Component id = 1]] 94. [TextFilterEx [Component id = filter]] 95. [TextField [Component id = filter]] 96. [WebMarkupContainer [Component id = 2]] 97. [TextFilterEx [Component id = filter]] 98. [TextField [Component id = filter]] 99. [WebMarkupContainer [Component id = 3]] 100. [TextFilterEx [Component id = filter]] 101. [TextField [Component id = filter]] 102. [WebMarkupContainer [Component id = 4]] 103. [TextFilterEx [Component id = filter]] 104. [TextField [Component id = filter]] - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5: The component(s) below failed to render
On 12/21/11 11:05 AM, Martin Grigorov wrote:
org.apache.wicket.WicketRuntimeException: The component(s) below
failed to render. A common problem is that you have added a component
in code but forgot to reference it in the markup (thus the component
will never be rendered).
This error means that Wicket sees these components only in the Java
component tree but doesn't see them in the markup tree.
How exactly do you pass the generated markup to Wicket ?
Let's have a simple example:
Simple layout/UI in XML:
Which is read and converted into an in-memory object tree:
frame
actionbox
fop-action
...
This is then taken and Wicket classes are instantiated for every
in-memory object.
In the constructor of every class (depending on its nature) there is
code to build the Wicket based object structure. Something like this:
ListView listView = new ListView("eachGuiElem",
formRoot.getChildren())
{
@Override
protected void populateItem(ListItem item)
{
ObjectBase ob = item.getModelObject();
item.add(getPanelFromObjectBase("cell", ob, model, form));
}
};
With that html content:
...
...
Where getOPanelFromObjectBase contains something like this:
protected Panel getPanelFromObjectBase(String id, ObjectBase ob,
IModel model, final Form form)
{
if (ob.getClass().equals(GListAndDetail.class))
{
return new GWListAndDetail(id, model, (GListAndDetail) ob,
form);
}
else if (ob.getClass().equals(GActionBox.class))
{
return new GWActionBox(id, model, (GActionBox) ob, form);
}
...
All classes starting with GWxxx are subclasses of Wicket Panels.
Every GWxxx class has an HTML file with the same name and the ending
html in the same directory as the class file. So Wicket should be able
to find the right markup. And with the right markup it should be able to
render not only the object tree but also the html representation.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.5: The component(s) below failed to render
Hello list
We built a rendering engine in Wicket 1.4 which takes a UI description
from an XML file and builds an HTML representation from that. Everything
worked fine in Wicket 1.4.x.
Now I tried to switch to Wicket 1.5.3. Without changing anything from
the rendering part, I now get this error:
> org.apache.wicket.WicketRuntimeException: The component(s) below
> failed to render. A common problem is that you have added a component
> in code but forgot to reference it in the markup (thus the component
> will never be rendered).
Below that message I get a list with all components.
We mostly use ListViews to build the UI:
ListView listView = new ListView("eachGuiElem",
formRoot.getChildren())
{
@Override
protected void populateItem(ListItem item)
{
ObjectBase ob = item.getModelObject();
item.add(new Panel(...));
}
};
So here is my question. What did change with Wicket 1.5? How can I make
our renderer work again? Where should I look at to find out whats wrong?
Thanks,
Adrian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
PropertyResolver and dynamic properties
Hello list I am working on filtering tables. To do so I use the FilterToolbar, FilterForm, etc. Everything renders perfectly so far. Now I am trying to implement my FilterState and run into problems. Looking into the sourcecode I noticed that the PropertyResolver of Wicket tries to find getter and setter methods. My problem with this is, that I need some dynamic getter and setter. This is because I work with my own UI and data binding engine. I define my UIs in XML and have a renderer render my Wicket UI. All UI fields are bound to Cayenne DataObjects via their absolute path. Now that is not much of a problem. My model knows how to interpret paths like this: table1.relation2.field3 But unfortunately the PropertyResolver does not. It only detects specific methods but does not support generic ones ( set(String key, Object value), get(String key) ). Now I could generate FilterState-classes for all of my DataObjects and bind those to the UI. While this works for UIs binding single tables only, it does not work for the example above where a field is bound using a relation to another table. Which brings me to my questions: - Can I somehow extend the PropertyResolver so that I can add my own getter/setter logic for my own FilterState class? - Can I somehow have the standard PropertyResolver call dynamic/generic setter and getter on my FilterState? - Is there another solution to this problem? Thanks for your help. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Could not find root element
On 9/9/10 6:43 PM, Igor Vaynberg wrote: very strange indeed. do you have any behaviors that write directly to the response? even that, i dont think, would cause this. create a quickstart and attach it to a jira issue. I guess I found the error. I have a UI engine which takes an XML formatted document and renders a Wicket based page from it (we call it Gozer, you know what it means if you know what XUL means :) ). All events are handled by a Controller which checks what state the page is in (edit, readonly) and which manages the content. Now we have a special component we can use, this is a listdetail. Basically it is a component which can toggle between a list and a detail view. The list is just a normal Wicket list, the detail is a repeater which dynamically renders the correct amount of captions and fields. We had some strange problem where the detail component was not rendered correctly after some events. We solved this with calling > DetailPanel.renderComponent() whenever something changed. Now that worked quite nicely. Until we started to introduce Ajax based commands. Now the call to renderComponent is called before the AjaxRequestTarget.addComponent(). Which means, that there is some text in the response before Wicket starts with the XML formatted ajax response. Which brings me to the question. How should we handle the renderComponent? How can we make sure, that components do rerender, but not doing so ourselves but have the Wicket framework ask for the rendering. Thanks, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Could not find root element
Hello list I have a very strange problem. I have some Ajax buttons on a webpage. They switch between list and detail view and start the edit mode. All of them are replacing a form tag on the page. When clicking on them in the wrong sequence, I get this error in the Wicket Ajax Debug Window: > ERROR: Wicket.Ajax.Call.failure: Error while parsing response: > Could not find root element And when looking at a few lines above, right after this one: > INFO: Received ajax response (11438 characters) I first get some HTML tags and then in the middle of the response I get the tag: > INFO: > > > ...some snipped HTML tags... > > >
Re: Wicket + security, what are the best options? Spring Security reached almost all the way...
3. Doesn't seem stable. [wicket-shiro] No maven repository (you have to check out trunk and build yourself) and has three different SNAPSHOT dependencies. I can't talk for wicket-shiro, but using plain Shiro from your Wicket project is quite straightforward. Use the integration from wicket-shiro as a pointer and integrate everything directly into your project. I did it this way and am very happy with it so far. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: convert wicket pages html to excel
On 5/6/10 3:42 AM, Jeremy Thomerson wrote: I've done this before. I'd actually suggest not doing this. Use jexcel [1] - it is much more reliable and you won't have users calling you saying "this spreadsheet won't open". I've written CSV before but then changed to Apache POI because of all those spreadsheet apps out there interpreting the separator character differently by default... Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Click
An advantage could be that cayenne is supported as a default persistent solution. There is not much magic in using Cayenne with Wicket. It depends on your needs, but basically this is all you need: public class DataObjectModel implements IModel Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dynamically Generated Wicket UI
Hi there On 1/28/10 6:18 AM, Josh Kamau wrote: How do i layout components dynamically in panel? i.e, there is not markup like a table to determine the position? if i write myPanel.add(field1) and myPanel.add(field2) and i want the fields to be laid out a) side by side b) one below the other, how do i do it ? As was mentioned before, with repeaters. I am working on Gozer - an OSS UI library - which is (the name already implies) heavily borrowing ideas from XUL. With Gozer you define your UI model within an XML file. The Wicket renderer takes this XML and builds an object tree consisting of Wicket based panels. Some of these panels are boxes. Boxes can either be of family xbox or vbox. Such boxes either repeat containing child-components horizontally or vertically. From what I read about your application, you will probably code something similar. This link contains some info: http://sourceforge.net/apps/trac/somap/wiki/GozerMain Talking about Swing there, but the concept is the same. The "form" containing the "formfield" in the sample image somewhere in the center of the page would be a xbox. Which means a simple vertical repeater which renders every formfield below the other. A formfield would be a simple panel in Wicket which inherits TextField from Wicket. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket security future - contribute!
Hi Alex i think we will not find one person who develops wicket-security allone - so who's interested? its not the part brings the most fun in wicket development area but a very very important part of every enterprise application - so contribute! lets define a security-subteam. I started with the built in security functionality and then moved to Apache Shiro. Shiro makes it very simple to authenticate users and to check permission from within your application code. And what I really like is that users of our tool still can personalise parts of those mechanisms when configuring their installation. Another plus is the permission based authorisation mechanism which makes defining and configuring permissions very flexible. So what I could contribute are classes to integrate Shiro into Wicket. If that is of interest. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDAP Authentication
Ryan McKinley wrote: take a look at Apache Shiro http://incubator.apache.org/shiro/ I found it much easier to work with... I agree with this. Apache Shiro is very easy to be used. Although the learning curve is a little bit steep because of the documentation. But once you get the hang for Realms and the (very few) classes you need to know, things become less difficult. We now integrated Shiro in our application and Authentication as well as Authorisation is a very simple process now. Ping me if you need some pointers to our implementation. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Passing parameters from markup to panels
Chris Colman wrote: I've thought of a very ugly way of doing it with the current version of wicket but it relies on quite a lot of smoke and mirrors and hooking into the component creation process. I'll give that a go for now. We went a similar but still different way :) We use our own XML formatted files from which we render HTML, Swing, FOP, Excel... Because of this the designer can not only change the fields and their bindings but also parameters like rowcount in lists. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Hi Sam > I'm probably revealing my inexperience with J2EE environments in asking > this, but how do Wicket programmers typically handle application "add- > ons" (or "plug-ins" or "modules"). What I (we) did was to imitate what Eclipse does. Defining hooks and having plugins attach to these hooks (and even define new hooks). We did this using a mixture of XML, Java, Script and DB tables. While we started with Swing, we "ported" this to Wicket as well. Our reason for doing so sounds similar to your thoughts: Deploying a core application and having other (third party) developers add, change and enhance to the core application. Ping me offline for details since this is very much non-Wicket stuff. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: singletons, pools, wicket, web services and architecture
Hello all Christopher L Merrill wrote: > We obviously need to keep very good separation between the business > logic and presentation layers, since there will be 2 presentation layers > :> We have a similar architectural design for our ORICO (Open RIsk and COmpliance) Tool. There is a web client and there is a native (Swing) client. What we did was to write Gozer (GPLv3). Gozer - as the name implies - has something to do with XUL. When using Gozer you describe your UI in an XML file which is converted into a object hierarchy which is then taken by a renderer (Swing, Wicket, FOP, Excel, ...) and rendered into the actual UI. This works quite good with Wicket and FOP, Swing lacks a bit behind in development but is promising as well. So what we have is a complete abstraction of the UI logic which is then reused for every platform without us having to rewrite anything. This of course comes with some cut backs, but if you are willing to take them, Gozer is the solution to build UIs very quickly. > 1) We need to have an "application" object/singleton to hold things > like "online/offline" mode - so we can, for example, bring the > application down for maintenance and give the user an intelligent > response. In Wicket, I think that would be the Application object? I > assume we'll need to make that reference a MyApplication object - how do > I expose that to both Wicket and the WS APIs? JNDI? I'd go the entry server way where access to the web application goes through some reverse proxy. When your application goes down, the entry server can return a intelligent response. Concerning the online/offline topic. What we planned is that the Swing client can be used in offline mode. To do so, you synchronise some data with an embedded database (Derby) prior to going offline. Since all our primary keys are UUIDs, synching is (at least theoretically) no pain at all. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket, FOP, Markup Inheritance and Markup Type
Thanks for all of your comments. Looks promising. > When used in html page it will use the HTML panel and when added in the > FOP page will produce the FOP markup. You don't happen to use that in a Swing application as well? :) I guess I will try that Wicket Tester hint in a Swing environment. Just to look how this works. For me the Wicket only version does not suffice or I would have to write my renderer twice. Once for Wicket, once for Swing. Cheers and Thanks, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket, FOP, Markup Inheritance and Markup Type
Hello everybody A quick question out of curiosity. Has anybody played around or tried to generate XSL-FO from within your Wicket project? What I mean is this: - Add an XML file to every HTML file. - Tell Wicket to use the XML instead of the HTML file for the markup. - Have Wicket do the markup inheritance magic and "rendering" of a FO file (instead of plain HTML). - Use the resulting FO to render PDF with Apache FOP. - Present the PDF file instead the HTML to the client. Anyone did so? Anyone played with Wicket and did so in a Swing application (instead the web environment)? I know, these questions may sound strange, but I am currently thinking about the possibilities of Wicket's markup inheritance and if it is possible (and makes sense) to use Wicket as a reports generator. Not what it is intended to do, but just pretend everything makes sense. :) Thanks for your comments. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache FOP and Wicket
> Why not? I was remembering that Wicket can manage any markup, not just > HTML . . > > Am I missing something ? Not sure. If you do, so do I :) I have written a renderer which takes an XML containing some UI description and either generates Swing, HTML (Wicket), PDF (FOP) or CSV from the same UI description (but from different templates). Although you can ask Wicket to generate the PDF, there is no direct link between FOP and Wicket. Wicket only calls my renderer and forwards the generated file to the user via HTTP. The problem with having Wicket generate your FOP files will be that you will have to write all UI elements on your own because there are no classes/objects you can use. hth, Adrian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
