I'm really struggling with a choice between the GWT Tree widget, which has been a part of GWT for ages; or the new CellTree, which is introduced by GWT 2.1.
The tree I want to present to the user is not particularly large, but I am very concerned about responsiveness.
The data at the nodes of the tree will be editable. By clicking on a node, the user will put the node into edit mode. Editing the more simple nodes will require only a single TextBox or TextArea; but others will involve several widgets, over which I want styling control via CSS.
I'm attracted to the CellTree approach because it seems to offer great flexibility and speed; however, the sample code for CellTree editing deals with only very simple data types: string, date, integer, etc. I don't know if CellTree is appropriate when you've got more complex node-editing needs.
What do you think? Is CellTree the best approach? Does CellTree replace Tree in general? What heuristics can I apply in choosing between them?
I'm using a CellTable with several custom input Cells, including one comprised of many widgets. It works great!
It took me a couple of hours to understand how to implement a custom Cell that could do complex operations - since a single instance of the Cell will flit around the CellTree, pretending to be many instances, you need to understand how it's getting its data and when it is refreshed and rendered. I learned a lot from the source of the DatePickerCell.
I can't speak for CellTree, but the CellTable is very flexible, was easy to program, and saves me hundreds of Widget instances.
Using CellTree is problematic. Because it hasn't good access to view implementation stored in CellTree. It cause problem (ex. for me :D) in making custom handlers for opening nodes with children by clicking on whole parent cell. Of course you can make custom cells by AbstractCell, where you must write own renderer.
I think this widget must be enchanced and more objects must be more visible for users.
Customizing CSS is simple. All what you have to do is extende CellTree.resource and insert own css based on celltree.css class names.
Related
I don't know if this is the right place to ask this question but I figured I might as well try to get an answer here.
My problem is the following: I'm a huge fan of Bootstrap and all there components so I'm genreally using them in every project im working on. So when I'm using container and container-fluid with different row's in between for sertain content-elements I haven't figured out a way to implement this inside the backend in an user-friendly way.
The way I used to do it was simply use the Grid Elements Extension to simply create containers, row's and col's and implement those within each other in the backend. Works fine, but its a whole lot of work for the user of the site to create content. I don't know if my explenation was clear, english isn't my first language and I don't know how to describe it in another way, but here's a picture of what I'm trying to say:
As you can see there are a lot of elements nested within each other so the user or admin has to actually "know" how bootstrap works to edit content without destroying the layout.
Is there any other way I can achive full flexibility for the content, e.g. a bunch of container's within a container-fluid as a wrapper and another bunch of cols's as children of the container?
I've tried to work with Mask, which seemed to be the solution at the beginning, but in the end I had to create one mask object for every possible way an element could be loaded, so there goes this option..
Does anyone else have this kind of "problem" or is there a simple (or hard, idc) solution I can use?
Thank you guys :)
I understand your "problem". My opinion: As soon as you have a page layout with multiple containers (container / container-fluid) and a flexible grid layout, I guess there is no better way without restricting flexibility or have some dirty logic / code. In some (minor) cases, you can help yourself with layout classes (DB field "layout") and some logic in fluid + a viewhelper to calculate the grid columns (e.g. imagegallery, where you can set the columns in backend and calculate the columns in frontend). But in my opinion, this is the most flexible way.
There are some people who solve this with new content elements and inline relation to its content elements. But IMHO this is more confusing for editors to see a grid layout in the backend and the possibility to flexible add content elements via content element to the container / column of choice.
A small, but effective useful helper for editors is to colorize your grid elements in the backend to help the editor to recognize different grids.
In my experience, editors can handle nested grids better than searching for multiple dropdowns in elements to understand grids.
Offtopic: editors survived templavoila, they will understand grids :-)
I have a smart gwt application which includes VLayouts, HLayouts, DynamicForms, Canvas, etc in a nested fashion.
One form comes inside of another in many places across the application.
But the tab order (Navigation using Tab and Shift+Tab) is behaving in a random order in many places.
Can anyone provide some suggestions for overall archetecture of the application?
For example
Which method should be used vLaout.addMember(myPanel) or
vLayout.addChild(myPanel)?
How to properly nest the components?
should globalTabIndex be used ?
If two forms are added to a VLaoyout, how can I specify the TabIndex to specify which form's components should be focused first ?
I didnt find any proper documentaion in smartgwt website. Please help me. Any kind of suggestions will be helpful.
addMember(Widget widget) shall be used - at least in most cases.
Organize them in logical panels (all components of a form in a form container, all the forms in a layout container and all the layout containers in higher order layout containers)
Depends on your case. You are not very clear on what you want to achieve with it.
DynamicForm is a Canvas. Use focus() at the form you want to be shown firstly focused to the user.
The http://www.smartclient.com/smartgwt/javadoc if very useful to find out about the objects supported methods and actions.
In most of the Activities and Places examples I've seen, people use a SimplePanel as the display for an ActivityManager.
I was wondering if there's a benefit to using a DeckPanel/DeckLayoutPanel instead of SimplePanel. It's fairly trivial to create a wrapper around a Deck panel that implements AcceptsOnWidget.
I haven't seen this topic discussed anywhere. Prior to MVP+Activities being commonly used in GWT, people generally used Tab panels (which internally uses deck type panels) and Deck panels to control switching between panels within a given view.
The difference between the two is SimplePanel.setWidget(..) will remove the previous child from the DOM and append the new widget whereas a deck type panel will use CSS to control visibility of the current panel (i.e. "display: none" to hide inactive panels).
If using a deck panel, it generally means you will have much more Elements in the DOM. I would imagine this uses more memory and makes the application "sluggish", even if those nodes are not visible ("display: none"). Is this true?
If this is true, why did Google use a deck panel style impl for TabPanel/TabLayoutPanel instead of internally using a SimplePanel?
Is one approach more favorable over the other?
Performance wise there is no difference. It all depends how you use it. In the DeckLayoutPanel all children are kept in memory. But if you would implement the same thing with a SimplePanel you need to keep a pointer to those same children yourself, so the memory footprint would be about the same. Unless with a SimplePanel you create and render a child each time it's shown and throw it away when hidden, which would possible be memory efficient (if the garbage collector does it's work), but it would be a hit on usability since rendering is expensive.
Second if you use a DeckLayoutPanel all it's children are created at once, while only one is shown. For performance this might not be optimal. So for this reason you could add a LazyPanel between the child and the DeckLayoutPanel, so it's only created when shown. But that might take some extra coding to make it work (because it's lazy you need to lazy initialze it which can cause some difficulties) However, still for the comparison between DeckLayoutPanel and SimplePanel it's only a matter of when you would create the children for the SimplePanel (all up front == same issue as with DeckLayoutPanel) and not something specific to the difference between DeckLayoutPanel and SimplePanel.
In general if you have a defined ordered set of children use a DeckLayoutPanel (like with a TabPanel) and if you have a undefined set SimplePanel is the better choice (like in MVP to show the current view).
DeckLayoutPanel internally holds collection of all your views (actually views that you've registered or displayed) in order to be able to determine sliding animation direction (depending if you go back or forward). Apart from this, I didn't notice that application become sluggish when switched from SimplePanel do DeckLayoutPanel. It's especially safe, when all your views are singletons. But please aware that in such case, when switching between the same view instance (for example main categories list -> subcategories list), DeckLayoutPanel may have some problems rendering sliding animation.
In my opinion there is no favorable solution - if you don't need "sliding" panels, I would not use DeckLayoutPanel (since all additional components increases complexity).
I'm designing the user interface. It has some static content and a lot of widgets.
Which is better?
HTML with a widget containing the other widgets
HTML containing all widgets
I addressed this very question in a presentation to a local JUG meeting the other day.
Which is better depends on what problem(s) you are trying to solve. Usually that means what pain you are trying to avoid from previous projects.
If you find it to be painful to include the static content in your GWT Module code, then your second option looks more appropriate. If the different widgets need to interact with each other (e.g. updating one refreshes the others), then your first option will contain the less pain.
Do you like the declarative style of GUI generation? If so, then consider using UiBinder which is included in GWT 2.
i'm also working on project with a lot of widgets (maybe over 250) and i think, one widget, which contains all others is the better way.
How about a mix? If there are widgets that logically go together, group them into a containing widget. Then put a smaller collection of widgets into your big containing widget.
Is there a good way to create a form in VB6 that can easily be embedded inside other forms?
On a few occasions recently, I've wanted to design and code a Form object that I could plug into several other "parent" forms. My goal is to create a centralized piece of code for managing several UI components in a particular way, and then be able to use that (both the UI layout and the logic) in more than one place. I'm certainly willing to use code (rather than the Design View) to load the child form.
The best I've come up with so far is to pull all of the interesting logic for the child form into a Class Module, and have each parent form lay out the UI (in a Picture control, perhaps) and pass that Picture object into the class module. The class then knows how to operate on the picture, and it assumes that all its expected pieces have been laid out appropriately. This approach has several downsides, and I'd like something a bit more elegant.
Take a look at VB6 UserControls; I think they are exactly what you need. You can create a UserControl within your project, add controls and code to that control, and then insert it onto a form just like standard VB6 controls. I've used UserControls to share UI layouts on many occasions and it works great.