Is it possible to create a GWT form without manually specifying sizes of components ?
I'm looking for layout managers that work a bit like in Swing, where you can simply pack things in a panel with a proper layout manager and constraints and never care about size/width/height. However it seems like in GWT all typical layouts (eg. Dock, Horizontal/Vertical) either require size parameter or don't exist (GridBag, unless you count in very limited FlexTable).
Such layout exists in GXT, but I would recommend to use plain-old CSS + HTMLPanel. It will give you in the end the same result, but in a little bit different way.
Related
as I'm turning back to the real core functions of typo3 (which I used last before templatevoila), I wonder how I can create an content Element which acts like a container, where I can place content inside with the wizard.
As I got really enough from the flux-fluid update chaos, I think best solution ist to bet on the core functions.
I know, I can do this also with ext B13 container, but if it's possible somehow, I won't use any extensions as I can do it hopefully with core functions.
there is no container functionality inside TYPO3 core itself. I suggest using the b13 container extension which is well maintained and doesn't add much overhead.
First it depends what kind of container you want to realize.
If you don't really want to pack/wrap the contained CEs you can use the CE 'Records' which enables an editor to show multiple records from different positions in one place.
In the default rendering those records are rendered each without further wrapping.
Of course you can change the default rendering. but that would be an extension (except you do it by typoscript or templates below of fileadmin/), at least the site extension.
drawback:
no preview in page BE module
you need 'another' place to store the contained CEs, otherwise the CEs. would be shown twice (you could use another page, or another column (which does not get rendered)
You can vary the layout by evaluating the layout field of the records CE.
another solution with core oly:
add further 'layouts' so all ' contained' CEs get a special wrap which can be gathered with javascript into a container DOM object.
I wondering why swt is so inconvenient to use. We as programmers have to produce tons of unnecessary source code. Here an example.
Label label = new Label(parent, SWT.NONE);
label.setText("labelname");
The minimum would be like this:
createLabel(parent, "labelname");
I build up a convenients library and I would like to know if there is something similar or why SWT or JFace don't go this simple way. Is there any drawback in having some more constructors that cover 80% of the programming task.
Have a more detailed look what I have done.
SWT: More Convenients Please
I suggest trying Google Window Builder Pro. It is a plugin for Eclipse that allows for the graphical development of GUI's in SWT, Swing, RCP, JFace and others. GWB writes the code which specifies the GUI layout and all you must do is write code to handle events.
As far as I know there is no such generic library. The one instance which provides some basic factory support for swt control creation is JFace Form Widget. Also have a look at this org.eclipse.ui.forms.widgets.FormToolkit.
From your implementation it appears that you are assuming the GridLayout as the default layouting style. Apart from that a control may have many layout related data like, its indentation (horizontal and vertical), span etc. Which is not easy to cover with factory methods.
If you don't want to put in the extra effort of writing the code for layouting the widgets and all then have a look at the Visual editor at http://www.eclipse.org/archived/.
Also, eclipse itself is moving towards the the Model Driven Generation (http://www.eclipse.org/e4/). It won't be a wonder if we will see a Netbeans like UI designer for SWT (by the way i have written a version for our tool using eclipse modelling framework and GEF).
Still I would suggest you to write the mundane layouting code by hand because it will improve your SWT understanding.
Bytes are very cheap to produce, and I'd debate that SWT "is so inconvenient to use" - well if it's automatically producing it, how is that inconvenient ?
Our computers are so fast that we couldn't even perceive the difference... and time saved is huge.
I just want to know if this is the proper way to go about splitting up widgets in GWT that get too large, or if I am missing the concept of widgets/proper GWT usage all together.
I started out with a single class (widget), PCBuilder. As PCBuilder became too large, I decided to branch off and make two classes SuggestionPanel, and BuildControlPanel, both of which just split off PCBuilder's code into separate classes that still have access to the methods in PCBuilder:
This way, in my PCBuilder class, I can do something like this to add the SuggestionPanel and the BuildControlPanel to the tabs (TabLayoutPanel) that are specified in the UiBinder of PCBuilder while allowing for SuggestionPanel and BuildControlPanel to have their own separate UiBinder specifications:
My question is: Is this proper? Part of me thinks "no" just because it's not a nice way of doing it. On the other hand it works just fine, and my web application is somewhat broken up into manageable "sections" which is what I wanted.
Thanks for any insight.
It's fine apart from the fact that you have circular dependencies between classes.
Why do SuggestionPanel and BuildControlPanel need to call PCBuilder? Is there any business logic in it? RPC maybe? Separate that into another class.
First, you might want to take a look at GIN - this handles dependency injection. This is good for testability.
Second, if your app goes beyond one "page", then take a look at GWT MVP.
You should not consider your PCBuilder as a widget. Quoting gwt -
You construct user interfaces in GWT applications using widgets that are contained within panels. Widgets allow you to interact with the user. Panels control the placement of user interface elements on the page.
Coming back to your question, my take is to create widgets only if I can reuse the same element more than once. The rest of my layout logic goes into the view. Layout shouldn't be a part of the definition of the widget as much as possible.To conclude, push styling in css, push layout in the views; widgetize only if re-usable (and core) or if adding additional functionality to existing widgets.
I have posted this question on the Ext-GWT forums, I am just hoping that someone here might have an answer for me!
I am struggling to do something I initially thought was simple but am beginning to believe is impossible...
I have got a "layout template" of sorts - simply consisting of a few GWT DockLayoutPanel's within each other and finally ending in LayoutPanels. GWT's LayoutPanel is designed to size the widget (or Composite) that's added to it to its full size and does so perfectly with pure GWT widgets.
The idea of my "layout template" is that I don't know the EXACT height and width of the very inner LayoutPanel's because I may set certain panels sizes (of the outer DockLayoutPanels) differently when instantiating this template. All I would like is to add a Grid component to one of the inner most LayoutPanels and have it size itself (height AND width) to fit as normal GWT widgets do (works perfectly with a GWT Label for instance).
I am VERY new to GXT (as in I started using it earlier today) and I do realize that GXT builds its Components differently to the way GWT builds its Widgets on the DOM.
Is there anyway to achieve the desired result? I have tried adding the grid to a ContentPanel with a Layout of FitLayout, I have tried AnchorLayout, I have tried adding the grid directly... Nothing seems to work... Any advice or even a push in the right direction would be greatly appreciated!
Thanks in advance!
Xandel
Just a note on this post and the direction I have taken. When I started my GWT project and I was learning the basics and reading through others posts and concerns and advice, the one bit of advice I overlooked initially was quite simple - when using the GWT framework use pure 100% GWT components only.
I initially ignored these fair warnings of fellow developers because in the age of open source tools, and open source projects, one develops the mind set of "Instead of building a tool which will give me certain functionality, let me rather see if someone else has done it already". This mindset speeds up development and almost standardizes projects and methods of implementation.
However, I have found over the last two months, that when working with GWT it is best to not follow this principle. Maybe because its not as widely spread as other frameworks, or demands a very certain type of coding style but non the less my search for a (simple, sortable, JSON loadable) grid component and (validating, neatly styled) form component has been nothing short of a nightmare.
This isn't because they don't exist. They do. I tried ext-gwt, gwt-ext, gwt-mosaic, and gwt-incubator. It is because many of the components break away from the very simple layout foundation that GWT provides (in other words, the panels that you place the widgets on mostly need to be the panels provided with the tools). This in turn makes mixing components and getting the desired result near impossible. Which in turn breaks away from the let-me-find-a-useful-component mindset.
Just an interesting and final point which I think might be worth mentioning. So due to my realisation of the above mentioned point, I set about to write my own grid and form components. Which I have completed and are working fine for me (obviously, because I wrote them , I don't suspect they will be useful to everybody else). But in the process of writing the grid component, and needing the columns to size and space themselves out automatically once drawn in their parent panel, I found that knowledge of the panels final width is not known until finally being drawn (this happens long after all your code executes). So ironically I set about building a set of panels that communicate to each other, from the parent panel (who ultimately NEEDS to have knowledge of its size) right down to the most inner panels so that when my grid component finally gets drawn, I can fire a method called onSizeKnown(int width, int height) and do whatever sizing is required.
After I completed this I could do nothing but laugh. Because it suddenly became clear to me why all the other GWT components out there require their own panels. I in essence had to do the same to get what I needed working.
So in short, if you are a newbie GWT developer like I was and are (is?) looking for cool stuff to make your project look awesome - this is my advice - if you are going to use an external framework such as some of the above mentioned - use ONLY that framework. Do not mix its components with other frameworks. Learn to love that framework, and build your project from the bottom up using their panels and design methods. If this scares you and makes you feel nervous and limited then do what I did and write your own using pure vanilla GWT components. You will save yourself A LOT of time in the long run by following this advice.
Xandel
This solution is for GXT 2.2.0 and GWT 2.0.4 *
While the original poster has since moved on I recently ran into this issue and thought I would post my solution in case anyone else stumbles on this.
There is no reason you can't add a GXT Grid directly to a GWT LayoutPanel. The problem is that the styling/positioning approach of the two libraries conflicts. Basically it boils down to the fact that the Grid is sized based on its parent's height attribute, which is not set meaning that the grid's body get assigned a height of 0 and the grid itself gets a height equal to that of the grid header (if present).
So the solution is to undo what GXT does once flow has passed back to GWT. Here is a template solution:
class MyGridWrapper extends Composite {
private LayoutPanel widget;
private Grid<?> grid;
public MyGridWrapper(Grid<? extends ModelData> grid) {
this.grid = grid;
widget = new LayoutPanel();
initWidget(widget);
widget.add(grid);
// Set the grid's vertical and horizontal constraints
// ... populate the rest of the panel
}
#Override
protected void onLoad() {
// onLoad is called after GXT is finished so we can do what we need to
// Redo what the LayoutPanel did originally
grid.el().setStyleAttribute("position", "absolute");
grid.el().setStyleAttribute("top", "0");
grid.el().setStyleAttribute("bottom", "0");
grid.el().setStyleAttribute("left", "0");
grid.el().setStyleAttribute("right", "0");
// Undo any height settings on the .x-grid3 element
El mainWrap = grid.el().firstChild();
assert mainWrap.hasStyleName("x-grid3") : "Wrong Element: " + mainWrap.getStyleName();
mainWrap.setStyleAttribute("height", "auto");
// Undo any height settings on the .x-grid3-scroller element
El scroller = grid.el().firstChild().firstChild().getChild(1); // FUN!
assert scroller.hasStyleName("x-grid3-scroller") : "Wrong Element: " + scroller.getStyleName();
scroller.setStyleAttribute("height", "auto");
}
}
The assertions are there to help protect against what is obviously very fragile code so beware that this is a GIANT, GIANT hack.
--
Just in case you're wondering where the GXT Grid's structure is defined, you can find it in a template file in the GXT JAR under com/extjs/gxt/ui/client/widget/grid/GridTemplates#master.html
Have a look at com.extjs.gxt.ui.client.widget.grid.GridView#renderUI() to get an idea of how the grid is built.
I'm learning to use GWT 2.0 and I'm trying to convert the StockWatcher demo to use the UiBinder. the demo uses stocksFlexTable.getRowFormatter().addStyleName(0, "watchListHeader"); to add styles, but when I add <ui:style> to my XML and move my CSS I can't seem to figure out how to make the style work because there is no stocksFlexTable.getRowFormatter().addStyle(). Does <ui:style> just not work with FlexTables?
I tried to deal with it as well with no success. I believe though that dynamic widgets such as FlexTable are not fully supported for obvious reasons - i.e. you can't preset the style for the nth row when you don't really know how many rows the table will hold. Also, providing some arbitrary way to do it for the first only, or odd rows etc. would require more expressive power than what the GWT developers seem keen to offer (they try to stick close to XHTML) and i believe they state at the wiki at somepoint that declarative syntax is by no means a templating language. Anyway, you can always experiment with #UiFactory and #UiField(provided=true) to try and stick close to GWT recommendations. But still, you ll have to set any such values programmatically.
I had success by removing the section completely and moving all of the css for the FlexTable into the application css file.