I need to have complicated grid for reflecting data with following features: sorting, filtering, pagination, and categorization (like in Notes Views). Additional features like resizing and reorderign of columns, add\remove columns by user, etc - are also welcome! )
Currently I’m considering Server-Side logic, like PrimeFaces (http://www.primefaces.org/showcase/ui/datatableHome.jsf).
Need support in how to integrate PrimeFaces into XPages? Or are there any suggestions, what library to use to reflect data in tables?
P.S. Currently I’m using DoJo EnchancedGrid. But it doesn’t support categories, this is first concern. And second - it is Client-Side logic, what is also not the best for my project.
Related
I am trying to figure out how to apply different filtering schemas for each page in an Analysis file in Spotfire Web Player/Consumer.
I have found that the Spotfire Analyst supports that (see image below) and I can create different Filtering schemas and apply them for each page:
However, the Spotfire Web Player does not seem to have such an option. I have checked the JavaScript API (link) but I cannot seem to find if there is such an option supported in the web player. Could anyone please share their experience if you know how that can be achieved
Have you tried putting the desired filters in a text area? Is there a reason the user has to use the filter panel?
In a text area filter you can specify your filtering scheme. Note I'm in 7.13 not X.
Hope you are doing fine.
This is my scenario.
I have multiple (20+) Liferay portlets that use grids/tables to display data.
Each portlet retrieves data based on a different criteria.
However, the grid is the same with some common functionalities such as filtering, pagination, data export etc.
Currently, each time we have to make a change in the grid style, I have to make the change in each of the 20+ portlets.
This is really inefficient and results in a lot of time wasted.
Hence, I was wondering whether it is possible to create a generic 'portlet' or 'composite' so that it can display data from multiple portlets?
To elaborate, the generic portlet/composite will contain the grid, filtering, pagination, export etc. features.
This generic portlet/composite will receive data from the various portlets and simply display it.
Hence, if I need to make any change in the grid style, making the change in only one place will suffice.
Has any one experienced such a scenario before?
Do you have any solution?
Thanks in advance for any help.
If you need only retrieve data by different criteria, have functionality like export data,print,pagination etc, you don't need 20+ different portlets you may use one portlet and have 20+ it instances, each would be configured like enable.export, enable.print, data.criteria and so on. Inside portlet your logic would build grid and data what you need.
If you really need Generic Portlet you may try to have all your 20+portlets in one .war. You'd simply include jsp's that are common within some portlets, extend controllers etc.
Even more... If you need to send data between portlets you may create javascript controllers that will send events each other, through Ajax get data and fill in your jsps(in that case you may use some templates). Please ask if something is unclear.
The best solution would be to use one portlet for retrieving all data, and generalise the data retrieving with one interface and different implementations - not with different port lets.
You can though try to use Liferay's Interportlet Communication facility to provide data from source portlets to target portlet - http://www.liferay.com/community/wiki/-/wiki/Main/Inter-portlet+communication
But it has it's own caveats - you'd either have to submit data in browser using AJAX or JS events, or have to use JSR-286 (Portlets 2.0) events that work on server-side, but require one to trigger an action in order to make events occur (i.e. open portlet with action URL and not render URL). More on it here - http://www.liferay.com/community/wiki/-/wiki/Main/Portlet+to+Portlet+Communication
I need to make a table with an editable column. Each row is a separate record. I want to be able to display hundreds of records, perform edits to them and then submit them back to the server for updating. I am not sure this is really supported by the forms infrastructure.
Is there a way to make a repeatable form such that I would get a list of results back? This seems to be the closest solution I can envision without writing my own in javascript. Any ideas on this would be welcome.
Don't reinvent the wheel. Just use one of the full featured js grids like jqgrid or extjs if you want the full pack of UI components.
I use jqgrid with yesod, edit rows both in grid and in outside panel and submit the changes back.
I think the problem with your approach is that you found your hammer (yesod forms library) and now looking for a nail.
You don't have to use every bit of yesod just because its there.
I have realized a full Xpages application width > 200 Notes View..and for translate I use the native option "Localization options" into Xpages settings.
All work very well (can now write the translation into -proprierties)
But...
In some Notes View I have the content of some column with embedded #Formulas string in the original language or the date of my field in the format of Domino enviroment (ex. there are #text(datfield;"S0") that return italian format gg\mm\aaaa)
Can I mix the native Multilanguage Database Notes Option with Locazations Options feature?
With native Notes Multilanguage database, is need duplicate the view setting the correct language... but Xpages support this feature when render the object Notes View?
p.s. For native Notes multi-language read this Redbook from page 65
First of all I would try to eliminate all the #Text(datefield) entries from the views that you are working with. This will allow the both the notes clients and the ViewPanes in your Xpage applications to automatically display the date in the correct format for the viewer of the application.
Unfortunately, from my testing, it appears that you cannot mix the native multilingual database options with the XPages localization options.
You cannot mix up those two options, because Notes-based multilingual database option is a part of Notes Client architecture.
If I were you, I create seperate views for XPages application. It's really waste of resources in the mean time (migration phase) but it's the most optimized way I guess. Instead of conforming old-style views, you may redesign your views according to what you need.
For example, in XPages, you don't need many columns to be calculated within the index.
There is no great answer for that :(
I have found that the only solution is a routine JS client insert into
*AfterPageLoad* event with **view.postScript**(Function JS client)
and *AfterRestoreView* event with the same call **view.postScript**
convert on.fly the content of my view.
I select the content DOM of my Notes view with dojo.query
Background
I'm going to develop a new web-application with java. It's not very big or very complex and I have enough time until it'll "officially" start.
I have some JSF/Facelets development background (about half a year). And I also have some expirience with JSP+JSTL.
In self-educational purpose (and also in order to find the best solution) I want to prototype the new project with one of action-based frameworks. Actually, I will choose between Spring MVC and Stripes.
Problem
In order to get correct impression about action-based frameworks (in comparison with JSF) I want to be sure that I use them correctly (in a bigger or a lesser extent).
So, here I list some most-frequent tasks (at least for me) and describe how I solve them with JSF. I want to know how they should be solved with action-based framework (or separately with Spring MVC and Stripes if there is any difference for concrete task).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
Thanks in advance for explaning how these items (or some of them) can be done with action-based framework.
I'll do my best to answer regarding Stripes. I've used Struts and JSF in the past, but not recently, so at best I have vague notions and feelings about them.
We are intimately familiar w/ Stripes, use it for most everything now, and really enjoy it. It is easy to jump into, supports many of the complicated scenarios, but you are also free to work OUTSIDE of it, which is really important when you want to build your own ajax widgets or talk to another system or something.
If you go the stripes route, I definitely recommend buying or download the book. It is a one stop shop for everything you need for Stripes, and is practically the only documentation for Stripersist (really nice feature, but NO web docs).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
This is similar. Core, Html, Fmt, etc. as well as any custom tags you find, inc. display:tag, pack tag, and create your own. However, obviously you do not deal at the component level now, you deal with a tag that determines what is on the page / sent to or from the server.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Stripes has many built in converters, and it is easy to create custom converters for your more complex data types. Stripes supports very complex data structures to be mapped with little hassle. Combined with Stripersist, for example, I can put my model object directly on the ActionBean, put a few of the fields on the form, and Stripersist will hydrate the model from the db (based on its PK) and update that with the fields I put on the form - all before releasing control to me on the ActionBean.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Navigation in stripes is based on what you name the ActionBeans, initially. There is no xml. Additionally, pretty urls are an annotation at the ActionBean level in Stripes 1.5, so you can do things like #UrlBinding("/{$event}/{model}") where /view/5 would take you to the "view" event handler for your Model object with the ID/PK of 5.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
While I only am vaguely familiar with the concept of conversation scope, Stripes has Wizard Form functionality, but I haven't used it and am unable to really expand on that. I think it is a similar idea though.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Not drastically different. Instead of components on your [action] bean, you now have Java or custom types. ActionBeans are created per request and thrown away, unless you do something like put it in session, or wizard, or whatever. This is nice, because all the instance variables get mapped to the data from the form, you use it, then throw it away, and don't have to deal with any synchronization issues like struts did. After you do your thing with the data, Stripes lets you send a ForwardResolution (OK status), Redirect, or Streaming (JSON, file, etc). The Redirect-after-POST pattern is implemented nicely with the idea of flash scope (3/4 down the page).
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Stripes allows validation in annotations on the instance variables on the ActionBean. They allow some defaults, required, maxlength, etc. or you can always create your own. The default is easy to add and flexible, while there is always the ability to make something completely customized.
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
This was my big problem with the JSF way of doing things. Even if you did get the widget right, you're still stuck with THAT widget. With Stripes, you can use whatever latest and greatest Jquery has to offer, and as long as you send the right GET or POST to the server, stripes knows what to do with it and can easily send JSON back. I think component frameworks fit a niche a few years ago much better when AJAX was hard, but JQ makes it so easy now.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
#UrlBinding, it's as easy as that.
My answer is not the one you want to hear: Don't switch from Component Framework to action framework
I switched the other way around after many years of action framework development and I'm never going back.
Of the 8 use cases you mentioned, only one comes to mind where Action frameworks are obviously better, and that is URL design / friendly URLs. It can be done in component frameworks as well, but much easier in Action Frameworks (especially in Stripes where you just annotate your ActionBean with the url).
I would advise you to try wicket, it is very easy to learn (much easier than JSF) and it let's you re-use many existing components as well.