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.
Related
I am wondering what is the best practice according to organization of widgets in Flutter. Let's image I am writing some bigger widget like side bar in the application. This widget consists of several smaller widgets (like title, some greeting, user data, list of menu buttons, etc.) that I know won't be reused in other widgets. And now my question is - should all of them be kept in the same file (widgets or methods that build these widgets) as their context is the same or maybe should I separate them into large amount of small files in order to write tests for them more easily?
Having a separate file shouldn't bring any testing-related advantages, as far as I know. Flutter unit tests are usually written in a separate directory anyway. Using a separate file for a widget is useful for readability and for re-use (as you mention) rather than for testing.
I personally try to have one public widget per file, and to break down complex widgets into smaller private classes (not methods) that reside in the same file. If a widget can be reused or if it's complex enough to make a file not readable, I declare it as a public class in a separate file.
Also: the more your codebase grows, the more you might find it useful to use directories (rather than files) to group together widgets that are used in the same "context".
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 :-)
There have been a lot of talk on MVP and how it seperate the presentation logic from the view's implementation. These designs are good but I still have a question unsolved regarding to widget.
To develop a widget, (or possibly many small widgets included in a typical website), specially those designed with UIBinder, I found it very difficult to test (or just simple display) a widget's view implementation. The obviously way is to add it manually to an entry point class and display the widget only, which works but seems very tedious if the widgets are getting more and more.
So the question is: what's the best way to just simply display a widget when it's being developed? and possibly to interact with it?
Since you need to display the Widget and interact with it in order to test it you need a functional testing tool.
One such tool is Selenium.
I'm fighting to understand the weird behavior of GWT Layout Panels. I'm wondering how GWT translate Layout logic into javascript and html. sometimes we don't get the expected Layout . something under the cover is done by GWT compiler.
the GWT documentation is not clear enough on how Layout is performed under the cover.
is there some good books or tutorials that explains well the GWT Layout issues?
thanks.
I don't know about good books or tutorials but here's a little information that may be helpful.
First, as you may know there's a big difference between the FooPanels and the FooLayoutPanels. These are two different sets of panels that are based on different layout mechanisms. The Layout Panels are the new stuff that seems to be suited better for layouts that have hard-coded sizes, Google Wave style. The older FooPanels (VerticalPanel, etc.) are based on HTML tables mostly.
FlowPanel - this is simply something that outputs your widgets as successive HTML elements in a single DIV. As documented: "A panel that formats its child widgets using the default HTML layout behavior".
DockLayoutPanel - Looking at the code shows that it hard-codes the sizes of the different regions according to what you specify in the children (north, east, etc.)
Finally - my experience has led me to abandon all usage of the Layout Panel system and rely only on HTML and CSS wherever I can. This means using HTMLPanel + UiBinder mostly and sometimes FlowPanel, rarely also some of the other panels.
Trying to understand and battle the Layout Panel system to do things that are not the "default case" was a waste of time. I'm not saying it's the best thing to do, but I just couldn't get the kind of control I wanted without this - especially with regard to elements that should automatically expand vertically. If you haven't already, take note of this from the GWT documentation about Layout Panels:
The panels described above are best used for defining your application's outer structure — that is, the parts that are the least "document-like". You should continue to use basic widgets and HTML structure for those parts for which the HTML/CSS layout algorithm works well. In particular, consider using UiBinder templates to directly use HTML wherever that makes sense.
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.