In my application I need two combo boxes, the content of second one depends on the current selection of first combo. Should I use JFace ComboViewer for this? or shall I directly use combo?
If I use JFace ComboViewer what flexibility I'll get? or how JFace ComboViewer is better than Combo?
For more clarity, I have to use only strings for my combo.
Thanks in advance!!!
The primary difference - as far as I am concerned - is the use of a ILabelProvider for ComboViewer, whereas you have to calculate the entries yourself for Combo. Whether to use one or the other depends on the specific use-case...
Combo is just the widget, ComboViewer wraps that so you use a model other than just strings. You rarely want to create and interact with plain widgets directly.
Related
I'd like to define an enum (or something) to give names to possible values of seletedIndex and define the order of destinations in, say, a Flutter NavigationBar in such a way that I only have to go to one place to change the order of the destinations.
The examples I've seen so far always require reordering be done in two places: one in the list of destinations given to the NavigationBar that have an implicit, invisible, unnamed index, and the other is a switch or a subscripting based on selectedIndex to establish the selected page. This seems like a bug magnet. Is there any way to set it up so I only define the order of the destinations in one place and have the list of destinations bound to the correct pages?
It seems to me that NavigationDestination should have a property to handle this binding or a "displayOrder" property, but I don't see this. If there isn't a better way, I guess I could write a function to construct the destination list based on an object (like an enum) that binds the numeric indicies to the corresponding page view, but this seems like a lot of machinery to create for a routine navbar task, especially in this modern OO context -- weird that selecting navbar pages would need a switch in the switchless programming world. Yet the example implementations have switches and two separate areas of the code need to be maintained to do one thing. But, what do I know; obligatory newbie disclaimer follows...
I think my question above was poorly phrased, based on ignorance and seeing some naive examples that suggested page navigation was generally done with an integer like selectedIndex. Once I learned about the Navigator class, and other navigation and List related builders, I saw the OO techniques Flutter provides for putting together hierarchical menus and such without the use of switch statements and integer indicies. So my answer to somebody like me who asks "do I really need to re-invent the navigation wheel" is to learn about Navigation Basics first.
I was assigned the task to rewrite our home-made templates with Perl Template Toolkit.
Our templates have the possibility to extract a fragment of the template (and then make HTML from it) instead of using the entire template.
How to do it with Template Toolkit?
The best solution I came with is the following:
Let we have a template x.html with fragment A.
The fragment should be extracted into new file. (I am to name it like x/A.html for consistency.) In the original template x.html it should be replaced with [% INCLUDE 'x/A.html' %]. So I could be able to use either the entire template x.html or its fragment x/A.html. Probably we may have several levels of inclusion like x/A/B.html.
Are there other ways to do it? (I don't like to idea to split it in subdirectories as described above, but haven't come up with a better solution.)
Are you asking whether there's a better way to extract the fragment from the parent template?
(Answer is: no, that's probably the best way.)
Or are you asking is there a better way to organize the extracted fragements?
(Answer is: no real best answer, everywhere will have their own house style - you aren't going to go too far wrong by picking any convention.)
Most common conventions for naming I've seen are subdirectories x/A.html and prefixes x_A.html. Whether you use the name of the parent template for x or you choose to group by functionality as simbabque suggested is another matter of taste: grouping by functionality scales better on larger and more complicated layouts where you have a great deal of reuse of components, but grouping by use case is conceptually simpler in smaller use cases with little or no component reuse.
Does Zend Framework have a nl2br filter? I can't see it - am I just missing it?
I imagine I could do the same thing with PregReplace...
When we have an existing PHP function nl2br it really begs the question: "do we really need to wrap a ZF filter class around a function?"
There are a few filters that actually do that.
In terms of forms for injecting a filter (and maybe other cases) I would say yes or when we need some more flexibility with additional options; basically extending the PHP function. I don't really see a need for this particular function and you should be fine to simply use PHP out of the box.
No, Zend Framework dos't have nl2br filter. If you want to use it then you should put it in your code where you want.
You can use any other methods also similar to that for achieving this.
I have about 6 forms to design with UIBinder that look almost the same, the difference is two or three fields. I was thinking about building one form with all the possible fields and hide or show fields depending on the case.
What do you think about this method?
It can work well. You can define a BaseForm class with UiBinder that implements HasWidgets, and then define SpecificForm1.ui.xml with something like
<custom:BaseForm>
<g:TextBox ui:field="componentSpecificToThisForm" />
<g:Button>A button!</g:button>
</custom:BaseForm>
and SpecificForm2.ui.xml with something like
<custom:BaseForm>
<g:Label>Something totally different</g:Label>
<g:Button>A button!</g:button>
</custom:BaseForm>
it works great!
I've tried something similar, and building one form where I hid/show the appropriate fields was the most simple solution. Another idea would be create a factory, which then builds your form according to your needs.
So, you basically create the components your form is composed of, and the factory wires them together via constructor dependency injection. Worked very well for me, and also has the added benefit that it is very easy to extend your form.
(I'll add an example later).
All the GWT / MVP examples I've learned about seem too simplistic to give a clear view what best practises are regarding displaying and handling slightly more complex model objects.
For example, most examples are something like a presenter that attaches a click handler to a few TextBoxes on the view...if save is clicked, the presenter's save() is called which simply gets the updated values, and we're done, MVP style. That's not so realistic though.
For example, let's say we have:
PresenterX
- gets a 'model' object, let's say any object with an unknown number of various primitives or whatever
ViewX
- should show the model object in a table, and/or allows it to be edited/re-saved
...so that sounds very, very basic. But, we don't know the amount of fields in the model object that we will need to display. So that might relate to a dynamic number of rows/columns. Probably no problem for a table...but how should the presenter give this to the view's table? As the model object that the view understands, or break it down into a bunch of Lists...that the view essentially still has to understand.
Also, certain fields might be editable, of which are unknown until we get the model object (something in the model determines what fields are editable, say) -- so who should be responsible for figuring out what is editable or not? Probably the presenter, but how do we refelct that in the view, the MVP way?
Lastly, let's say there's a 'save' button on the view...who's job is it to figure out all the rows in the table which were changed?
Seems to me that the view either needs to understand the model more, or the presenter needs to really understand the view more -- neither of which are nice MVP :( ... Or perhaps there should be some intermediary object.
I know there are some nicer/newer helpful ways for this kind of stuff (Editors/RequestFactory, etc.), but I'm looking for suggestions on the above scenarious.
As I understand it, MVP is a line with M-P-V points. So P interacts with both, but M and V only with P.
Also, one of design objectives of MVP is to have a testable P and M, which means that V must be replaceable with a mock version. So, V should not expose any implementation-dependent interfaces (e.g. HasClickHandlers instead of Button).
Now, if V should show generic table, you should create generic methods: addColumn(..) to define columns and addRow(..) to add data. The new CellTable is pretty flexible and supports adding columns dynamically.
About changes - V should notify, P should act. Also, there are the new Editors, which IMHO do not fit nicely into MVP, but are supposed to be easy to use.