i am new to GWT and GWTP and the question sounds stupid.. Can I make an abstract PresenterWidget or similiar?
Like in normal Java extending the "class" and reuse / extend the logic. But not only the class, the whole thing of View and Presenter. I try to explain my initial situation and maybe you have another idea.
The image hopefully helps to explain it. The "Main-Tab" and every other tab consists of a collection of views which have the same base structure and the same logic.
the base structure consists of
border around EVERYTHING
an image (the wwitch)
a title
a textarea
a PresenterWidget which is added to a contentSlot of the parent (the menu left)
and below the base are view specific components like buttons, text or any other widget. So a main part of the view with logic is repeading. If the switch is "toggled" the view is hidden (the textarea and any childs / view specific components) like the lowest view in the picture. Furthermore the PresenterWidget left changes the color.
The logic is working, but now I am searching a proper way to solve this without repeading code and the possibility to add child elements which are hidden as well by toggling the switch. Can I add to a PresenterWidget child widgets and define where there should be added? like: Even if this is possible, it feels a bit inconvenient.
Thanks in advance.
I just want to post the solution:
I have now a simple Composite (KPICommonView) for the switch, title and the description. It got another FlowPanel below the description, where the specific components will be added later. For this the Composite implements "HasWidgets" and overrides the "add(Widget w)"-method which is called by UiBinder if the Widget is added and has child elements.
<own:KPICommonView title="First Header" description="I am a happy description :)" anchorToken="{nameAnchors.getFirst}">
<g:Label>child component</g:Label>
</own:KPICommonView>
I am not sure if I do a PresenterWidget for every segment and every PresenterWidget has one of the KPICommonView added, or if I do one normal Presenter which adds more than one of the CommonViews.
The CommonView furhter creates the PresenterWidget for the menu item on the side. It gets the attributes from the constructor (anchorToken, title) and adds it to the slot (which happens ugly, because the View has hard coded the parent saved to call "addInSlot()". The repeading code for the switch is handled by the KPICommonView.
Related
I'm developing a custom table component for very large and very custom content. Therefore I decided not to go with TableView, but start from scratch (i.e. Control). I adopted the idea of the VirtualFlow to create and manage only the visible part of the table and reuse cells that have become invisible. However I needed virtual rows and columns.
My CustomVirtualFlow implements layoutChildren(). From the component's size and scrollbar positions I know which cells are visible. If necessary, I add cells to the VirtualFlow. I then update the content and css pseudo class states (selected, focused, ...).
This works almost fine ... currently, my only problem is that the css styles are sometimes lagging: newly created cells are shown with e.g. wrong backgrounds for a moment and then get correcteted with the next pulse.
My explanation for this is that JavaFX performs layout in two passes:
first a css pass and secondly the layout pass that calls layoutChildren().
The css of newly added children (during layoutChildren) is therefore not processes correctly.
I tried to call applyCss() directly, which helps, but seems to do too much because it takes a lot of time.
My question is:
How is the correct way to add nodes during layout, i.e. if the size of the component makes it neccessary to use further nodes?
If it is not during layoutChildren(), where else should I do it?
I have a question regarding coded ui UIMap.
Every time I record an action on the same application, coded ui generates a new object for the same window in the application.
It looks like:
UIAdminWindow
UIAdminWindow1
UIAdminWindow2
and so on...
every window class holds different buttons, even though it's the same window.
Thus it's very hard to keep code maintenance.
What i would like is that every time i perform actions and records on a window, even if not at the same time, the already generated class for this window, will be updated with the new controls.
any suggestions to why it happens?
Thanks a lot!
You can clean up your UIMaps by doing two things:
Use the UIMap Toolbox (from codeplex) to move controls within the UIMap so they are all under one control tree.
When you have duplicate UI controls, go to the properties for the action that references the duplicate control and change the UI Control property to point to the original control in the UIMap.
The duplicate trees should now be unreferenced and you can delete it from your map, keeping things clean.
And yes, it's a pain to do, but it's worth it for maintainability.
In UIMap.uitest you can change the action name and the control name for better maintenance.
For example: you can set UIAdminWindow as FirstAcessWindow or other name that will express comfortably the control or the action.
What I can guess is that there is some randomly generated content or element identification data such as class or title that may be causing it. This may be caused by different username for example. Also you can update the element from UI map element tree.
Background/Context:
I have a HBox as a parent and many child Nodes (Buttons, TextFields, Labels…). The HBox is a child of other container (BorderPane/VBox/Grid)
My questions:
How do I dynamically remove/exclude the parent (HBox) and all its children from layout?
I am looking for some three-state property on Node (like in Microsoft WPF):
Visible – visible and participate in layout
Collapsed – is not visible and do not participate in layout (applies to its children as well)
Hidden – is not visible but participate in layout
http://msdn.microsoft.com/en-us/library/ms590101.aspx
What options does JavaFX offer?
My solutions so far:
hBox.setManaged(false);
this work only for HBox, its children are still present
root.getChildren().remove(hBoxTop);
root.getChildren().add(hBoxTop);
Well, this looks like it could work.., but for example in case of root being BorderPane, once I remove/add and remove the HBox, the space after it remains unused. I already tried requestLayout() but id does not force thr rrot to fill it. Am I missing something? Is it correct approach to this problem?
Edited:
Well, I got this working.
Dynamically removing and adding for this specific case can be achieved by:
Remove:
root.setTop(null);
Add:
root.setTop(hBoxTop);
When I did not call setTop(null) on removal, BorderPane still reserved space for HBox (even after removal from its children).
IMHO: it is not very good model as it is parent-container specific. For example if I change, BorderPane to VBox a I had to change these methods as well. For VBox, remove/add on children collection works but I need to remember index so that HBox appears at same place after calling add.
Using root.setTop(null) is not a good idea because as you say it's specific to BorderPane.
I think the best solution is to use:
root.getChildren().remove(yourPane);
And use layout methods to place your other childrens as you want.
But maybe you should not use a BorderPane in the first place with the behaviors you want in your application.
Notice you can also do root.getChildren().clear() to remove all component and add it again to your layout but differently.
I have a simple ContactEditPanel which contains a form and a number of textfields. Up until now I included an AjaxSubmitLink in this panel which, if the form content is valid, saves/updates the Contact instance contained in the Panel model. So far so simple. However now I'd like to remove the link in order that I may, depending on the context in which I use the ContactEditPanel, place the submit link at different levels of my overall component hierarchy. For instance in one context I'd like to use to flip between ContactEditPanel and ContactViewPanel with a bar of actions above the current view (edit | save , cancel). Another context would be to use ContactEditPanel in a standalone way (maybe part of a multi-step process) with just a save link below.
I was contemplating refactoring my ContactEditPanel to extends FormComponentPanel rather than Panel as described here but I'm not sure whether this is the right approach and I'm having trouble wrapping my head around this.
Any help would be most appreciated!
Many Thanks,
A
Your using the panel like a FormComponent so extend FormComponentPanel, it will allow you to keep all the validation you write contained to the component and also allow you to reuse it as you wish.
Just think of it as you've created a new FormComponent, like a TextField or DropDownChoice.
my question is about view controllers, delegates and all that in general. I feel perfectly comfortable with UIView, UIViewController, Delegates and Sources, like UITableView does for instance. It all makes sense.
Now I have implemented my first real custom view. No XIBs involved. It is an autocomplete address picker very much like in the Mail application. It creates those blue buttons whenever a recipient is added and has all the keyboard support like the original.
It subclasses UIView. There is no controller, no delegate, no source. I wonder if I should have either one of those? Or all, to make it a clean implementation.
I just cannot put my finger on the sense a view controller would make in my case. My custom view acts much like a control and a UIButton doesn't have a controller either.
What would it control in my view's case?
Some of my thoughts:
For the source: currently the view has a property "PossibleAutocompleteRecipients" which contains the addresses it autocompletes. I guess this would be a candidate for a "source" implementation. But is that really worth it? I would rather pass the controller to the view and put the property into the controller.
The selected recipients can be retrieved using a "SelectedRecipients" property. But views should not store values, I learned. Where would that go? Into the controller?
What about all the properties like "AllowSelectionFromAddressBook"? Again, if I compare with UIButton, these properties are similar to the button's "Secure" property. So they are allowed to be in the view.
The delegate could have methods like "WillAddRecipient", "WillRemoveRecipient" and so on and the user could return TRUE/FALSE to prevent the action from happening. Correct?
Should I maybe inherit from UIControl in the first place and not from UIView?
And last but not least: my custom view rotates perfectly if the device is rotated. Why don't all views? Why do some need a controller which implements ShouldAutoRotateToDeviceOrientation()?
Does it make sense what I wrote above? In the end I will provide the source on my website because it took me some time to implement it and I would like to share it as I have not found a similar implementaion of the Mail-App-like autocomplete control in MonoTouch.
I just want to learn and understand as much as possible and include it in the source.
René
I can answer part of your question.
I just cannot put my finger on the
sense a view controller would make in
my case
The ViewController is responsible for handling the View's state transitions (load, appear, rotate, etc) These transitions are used mainly when you use a navigation component (UINavigationViewController, UITabBarController). These components needs to received a ViewController that will handles the view's transitions.
For exemple, when you push a ViewController on a UINavigationViewController, it will cause the ViewDidLoad, ViewWillAppear, ViewDidAppear. It will also cause the ViewWillDisappear, ViewDidDisappear of the current ViewController.
So, if your application has only one portrait view, you don't need a ViewController. You can add your custom view as a subview of the main window.