Why use CustomComponent for Layouts in Vaadin 7? - java

Both the Book of Vaadin and the Vaadin training course recommend using acom.vaadin.ui.CustomComponent to contain a Layout.
I can understand this in pure theory, to encapsulate the contents without needlessly exposing a specific layout such as GridLayout or HorizontalLayout. Encapsulating has benefits of:
Encouraging de-coupling between classes
Makes it easier to change the layout without having to change the declarations in the outer class.
But in terms of practicality, I assume the rendering of a CustomComponent means extra HTML/CSS layout instructions such as perhaps an another div. The last thing Vaadin rendering needs is yet another layering of HTML structure.
I wonder if this might be old folklore. Perhaps using the visual composing tool in Eclipse accepts only CustomComponent objects rather than Layout objects? (Just a wild guess, I have no knowledge)
➤ Alternatively, why not just declare in the outer class a reference variable of type com.vaadin.ui.Layout to get the same encapsulation?
➤ Am I exaggerating the impact of adding a CustomComponent to Vaadin rendering?
➤ Is there some other benefit of CustomComponent which I’ve failed to perceive?

You can compose the content of a CustomComponent with the Visual Designer. This saves a lot of time in the development process

The main advantage of the CustomLayout is, that you can place your components inside HTML code which you otherwise can't generate via vaadin means.
If this adds more div/html as with native Layouts depends on the specific case.
We ususally use it only when a clean Vaadin only solution would introduce more components/div's or is not possible to implement.
The second idea is the separation of layout and logic, which can be implemented partially with this Layout. You just specify which components you have and then a UI designer (in theorie) could make your HTML code, with the correct blocks where your components will be placed.
In real life I do not find this a real advantage, since the whole CSS, sizing etc. is anyway done with vaadin.

Related

How to create a modular UI using MigLayout without nesting multiple panels?

MigLayout is a highly versatile layout manager for Swing, SWT and JavaFX.
As per the documentation, it should be possible to (re-)create any given layout with just a single instance of that layout manager.
However, I could never figure out how to create a modular application with decentralized control over layouting with that single instance:
I have a parent panel that controls where individual components contributed by submodules go.
Aiming for decoupled and independent submodules, those components are free to choose whether they do their layout with MigLayout or with any given layout manager. Thus, they hand out an instance of Node (or JComponent), and I end up with nested layout managers.
Are there any emergent/good/best practices for achieving both decoupled architecture and adhering to MigLayout's single-instance paradigm?
I understand what you want to do and have tried similar approaches. I found no generic solution; either you nest the layouts or you come to some kind of agreement between modules on usages of ranges of cells (this is what I usually end up with when for example generating search screens).
I ended up with one conclusion; having totally independent modules putting stuff on a screen works fine technically, and if you can make a high degree of separation part of the layout style, it might also work for the user. But I found that the resulting screens usually are not very user friendly, especially if there are multiple layers of construction. So I stopped trying to dynamically construct screens and just build a screen to match the task at hand; there is the end user screen, some custom controls, and maybe the occasional task specific panel (/ pane).

Create java GUI programmatically rather than using java look and feel

the java programming offer you to create Java GUI (J2SE) with two options. As we known, there are programmatically(Coding from scratch) or using Java look and feel(Drag & Drop). As my experience, its very easy to create Java GUI using java look and feel rather than programmatically. So, i'm frequently using java look and feel. ;)
Now, i'm know its wrong, because its limit us to create dynamic application. So i wanted start to create java application (J2SE) programmatically. But my question is very simple, how to create this frame programmatically as below :
As we know, its very simple using Java Look & feel (Just drag and drop). How to create space between jLabel1 and JtextField1 as we desired? And how to create leading space(Space below and after) between jTextField1 and jButton1 as we desired?
I know this is very stupid question for java expert, but perhaps this question can help other people(particularly java beginner) to start learning Java Programming and not doing as what i'm doing now. :)
Thanks for your advice, sorry for my bad English and possible duplicate question. :)
In Java, you typically create a hierarchy of JPanels (Swing), each having a suitable LayoutManager (GridLayout, PanelLayout, BoxLayout, GridBagLayout, etc...). See the link below for details;
http://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html
Using layout managers is the best dynamic approach for creating scalable and dynamic UIs, but there are lot's of drag-n-drop utility applications that set layout manager to null and thereby allow for pixel-based exact positioning of your different components. In your case, a JLabel, a JButton, and a JTextField.
Hence, to create the exact UI you shown, go for null-layout and place your component instances on upper-left-corner (x,y) positions relative to your frame's origo (again, upper-left corner).
If you use the Drag-and-Drop interface, it should generate some code for you. Examine this code and use it yourself, making changes as you like. The DnD interface is nothing but a layer on top of the code.

GWT CSS, Layout and LayoutPanel?

I'm trying to build a slick-looking GWT panel (my first one) and am stuck trying to decide how to handle its layout.
According to the Layout Javadoc:
Helper class for laying out a container element and its children.
And the LayoutPanel Javadoc:
A panel that lays its children out in arbitrary layers using the Layout class.
So it seems like you can:
Extend a ComplexPanel and use a Layout to manage its layout; or
Use a LayoutPanel which seems to have this functionality built-in; or
Just add elements to an HTMLPanel and use CSS to perform all the positioning/layout
I'm not 100% sure, but this feels like you have these options (and possibly others) because they offer benefits over each other in different circumstances, or because the GWT API has changed a lot and newer layout methods have been added over time.
If the former is the case, then security and performance are my only priorities, so I ask: is one method more performant and/or secure than the others? And if the latter is the case, then which method is GWT's newest and most encouraged? It would seem to me that the most control would be to leave everything for the CSS and not use Layout/LayoutPanel at all!
LayoutPanel uses absolute positioning, and it also provides size to its children. I like to use it for my outmost layout container, as it occupies the entire browser window and resizes its children when that browser window is resized.
For inside widgets (e.g. menus, main area) many people like to use VerticalPanel and HorizontalPanel (or, even LayoutPanel) for their simplicity. I avoid using these panels as they offer rigid, table-based layout. I prefer to use either HTMLPanel or FlowPanel, and achieve the desired layout through CSS.
Note that I would not use "old" or "new" attributes when discussing the pros and cons of different panels. They all translate into standard HTML. If you are comfortable with CSS (a lot of developers aren't), then you should use CSS as much as possible, because this is what browsers are optimized to do, and because you can build more fluid, consistent and future-proof (i.e. much easier to change) layouts with it.
What kind of app are you building?
Do you need 'user-positioned splitters' between panels?
Do you need separate scrolling panels?
If not, stick with CSS.
Start with an HTML/CSS mockup and then convert that to a GWT UiBinder file. Particularly when it comes to responsive web design, you can get a HUGE HEAD START by starting with an off-the-shelf CSS framework like Twitter Bootstrap.

Swing and lazy loading components

I have used the Eclipse plugin Visual Editor to construct Java Swing interfaces. As I'm not a big fan of the code WYSIWYG (UI) editors generate, I wanted to optimize it, when I noticed, that the editor implemented all elements using lazy loading like this:
private JPanel getSomePanel ()
{
if ( somePanel == null )
{
somePanel = new JPanel();
// construct the panel
}
return somePanel;
}
I know that lazy loading is used to get better performance, when the objects in question are not used immediately. However for most user interfaces this makes less sense, as a window for example should usually show all components on it right from the beginning. This is also the case in my situation where I have a rather simple clear layout, where all components are expected to exist when the window is displayed.
Visual Editor added an initialize call in the root container's constructor in which the root panel is constructed and all the other elements are added (via lazy loading). So actually all components are created right when the root container is constructed, just nested into multiple methods.
Is there actually any use for lazy loading in this case? In which UI cases should I use lazy loading? And when using lazy loading, am I actually even allowed to access the member variables directly - or should I call the getter each time?
Thanks!
When you use lazy loading, you should always use the getter each time you access the member variables. This is a fundamental part of lazy loading.
However, in this case you described, there is no reason to use lazy loading. I have to wonder if the author of Visual Editor didn't just have some thing for lazy loading where he felt it always needed to be used, or just decided that he wanted to use it in the tool for some arbitrary reason.
You are exactly right about UI's where components are generally all loaded when the panel is constructed because they're all visible. There are some cases where parts of a panel may appear and disappear based on other choices on the panel, and it's conceivable that you could use lazy loading in these cases. My point of view, however, is that people are likely to click around an interface anyways and use all the different tabs and options, so you might as well load everything to begin with.
Obviously, there's something different going on when you're talking about loading data. If you have a drop-down that's hidden when the panel comes up and has a lot of information if loaded, you may want to not load the drop-down until it becomes visible. I still see no reason not to instantiate the drop-down right away, though, even though it's hidden.
I would not consider lazy loading to be the norm behavior for a panel at all. I could not offer a reason why Visual Editor chose to generate code in this manner.
I'm not a big fan of the code WYSIWYG
(UI) editors generate
Me either.
Is there actually any use for lazy
loading in this case?
I don't think so, the creation of the component takes no time so all components should be visible when the GUI is displayed.
To me the bigger concern is the data. If your data for components like combo boxes and tables comes from a database you may not want to load it all up front.

Custom Swing component: questions on approach

I'm trying to build a new java swing component, I realise that I might be able to find one that does what I need on the web, but this is partly an exercise for me to learn ow to do this.
I want to build a swing component that represents a Gantt chart. it would be good (though not essential for people to be able to interact with it (e.g slide the the tasks around to adjust timings)
it feels like the best approach for this is to subclass JComponent, and override PaintComponent() to 'draw a picture' of what the chart should look like, as opposed to doing something like trying to jam everything into a custom JTable.
I've read a couple of books on the subject, and also looked at a few examples (most notably things like JXGraph) - but I'm curious about a few things
When do I have to switch to using UI delegates, and when can I stick to just fiddling around in paintcomponent() to render what I want?
if I want other swing components as sub-elements of my component (e.g I wanted a text box on my gantt chart)
can I no longer use paintComponent()?
can I arbitrarily position them within my Gantt chart, or do I have to use a normal swing layout manager
many thanks in advance.
-Ace
I think that the article i wrote a few years ago for java.net is still correct today. Doing everything in one monolithic class gets you going faster in the beginning, but becomes a mess quite fast. I highly recommend doing the separation between the model (in your main class) and the view (UI delegate). The view is responsible for:
interaction with the user - mouse, keyboard etc.
painting
creating "worker" subcomponents as necessary
In the medium and long run this is the approach that has been validated over and over again in the Flamingo component suite, which you can use as an extra reference point (in addition to how core Swing components are implemented).
Using UI delegates is a good idea if you think that your component should look different for different Look And Feels. Also it is generally a good idea from design point of view to separate you presentation from your component
Even when overrding paintComponent you can still put any sub components on it.
Using null layout you arbitrarey position your components. Alternatively you can use layouts too.
Here is a very good starting point for you.

Categories