I'm using Ext Js 4.1.1.
In many of the Ext JS widgets I am using, I am required to reuse data. For example, the items collection for buttongroup in top toolbar may be repeated in menu bar on the left side. For manageability, I should be able to have the array for items collection defined in a separate file (which could potentially follow the class naming convention for auto loading).
The approach I tried is that I am creating a class that has statics. Each static function returns an array that can be assigned to items collection of the widget. This works but I believe that using a class is an overkill if I can just use an array. Any suggestions?
Not sure if it will be useful to create separate objects for storing configuration for toolbars, buttons groups and etc. In the context of the extjs in almost all cases you need not only manage configuration but also behavior of a component.
The best way for me here - creation of generic/basic predefined classes, where you can state not only configuration but work around the behavior, add you'r custom events and process any unexpected results. After it you can easily reuse and extend it easily.
For instance you have a menu or a toolbar with 3 items A, B, C. For sure you need to know wherever you use it what was clicked (for instance) A, B or C. Creating a class and manages required events you can fire you own events which will tell you what was clicked and it is much easier to use in any context where this component will be used. Add post and pre processing, template methods and etc...
Creating a big file just with configuration is not readable and not extendable, will be a case whre you will need to add functionality and behavior to all such generic components and it will be not easier to do with just arrays or simple configs. Separating even just simple general components having just simple configuration (in the beginning) will bring more expressive in the code structure and readability and in the later time gives you the power to manage it.
Pure configurations can just keep the code accurateness and re-usability but what about behavior for in almost cases you need to control..
The design, maintainability and extensibility are very important points in every big web-applications and in context of extjs 4.
Related
I have a large app with a structure and UI that has been designed to meet the original requirements.
I am now faced with a situation where I have to make an alternative read-only "view" of certain parts of the app for embedding in an iframe (I have no say in this, this is how it has to be).
I'll be referring to these two ways of viewing the app at the "display context".
I am struggling with visualising how to achive this, I can see two solutions both of which have distinct disadvantages:
Have lots of ng-if directives attached to template elements, the ng-if would be bound to the current display context of the app and show/hide elements depending on how it was being used. Even if these were one-time bindings, it would potentially turn the templates into an unreadable mess of nested ng-ifs everywhere
Create entirely separate templates for the two different display contexts. While much cleaner than the first option, it would mean a lot of duplication and maintaining two templates per view whereas previously it would be one.
I should add that the nature of the views is very ng-repeat heavy, a list of data containing categories, each category contains items, each item contains a multitude of data, at each level data may need to be hidden/displayed/manipulated for display depending on the display context. I have made heavy use of directives and components to break things up into logical chunks, however these directives and components are still very much geared towards the original use, rather than the newly required one.
I have also considered creating an entirely new app for this, however I'm not sure this would bring any benefits as I'd be using controllers and injecting services containing tons of stuff that would be never used, I'd also be increasing my duplication problem.
Does anyone have any feeling, suggestions on a good way forward for this as at the moment I'm feeling anything is going to be horrible.
Many thanks
Long story short, let's say one app has multiple pages with:
a form
a list
pagination
each page may require (now or in the future) custom actions to be implemented
My question is, witch is the preferred Backbone way of handling this and why (please argument) ?
Define, a pagination view, a pagination collection, a search model, search view, etc, and initialize each one as a child view in all the necessary pages. This means we will have to append child view elements into the 'master' element, and handle all the communication between these in all necessary pages.
Define a pagination view (with it's own pagination collection and search model) and extending it across all the necessary pages. This does mean that we will have to make use of template partials (for forms, pagination, etc) and bypasses the need of handling communication between child views while also removes the need of appending/removing child view elements.
Please add your way of handling these cases if not found above, remember to argument.
My personal opinion would be 2. And that is because it removes a lot of hustle with communication between child views and it makes everything much more easier to read just by extending classes, instead of having to 'manually' init child views. It also gives one the option to rewrite behavior per page when needed.
I think #2 is a poor choice.
It's a very good idea to keep templates as simple as possible. They are basically just the markup that's generated for some input object. In order to get that object to the template, in MV* frameworks you have Views, that can either pass a model to the template or send some formatted data to the template (I prefer this where possible).
Partials just create markup. You'll still have to handle events, updates to the DOM and rendering inside the view. If you only use one view it will have to handle a lot of things, something associated with poor maintainability and a more bug prone codebase.
You'll either have a lot of code in the views, or you'll end up with a lot of mixins or doing a lot of inheritance - and I have no idea which is worse.
Big things are a lot harder to test and to reason about. Avoid doing big things.
I think that another big problem with the template partials approach is the fact that you cannot rely on type information (something like interfaces), on the object that ends up in the template. It's probably easy to make it work when you have a partial or two that you just created, but, in time this information will get lost, leading to a bad development experience.
You'll need to make sure views unrelated to your changes are kept updated with the partial changes you just made for a feature.
Keep in mind that software is never done. Things always change.
Instead of thinking about relationships between models you'll have another complex challenge that you need to handle: the coupling of views through partials.
The alternative is a lot better. Composing specialized views is a good approach because each has it's own internal, smaller state and just it notifies listeners when some action takes place. Nobody cares about what's going on there until something happens and then you just get concrete data.
Going with #1 helps you deal with complexity in your application while allowing you to reuse them in other contexts.
You know, like in CCleaner app where main activity is on the left side of the app and the right side area is changeable fragment.
http://cache.filehippo.com/img/ex/3049__ccleaner1.png
How to do it? I imagine I could do it by putting all fragments in the same place and just change their visibility to show just 1 at the moment, but that would make the code a whole lot of mess.
I've done this in the past by using UserControls. It's worked nicely for things like choosing payment methods (cash, cc, cheque...).
There are a couple of options for changing the display, either have all the UserControls present on the form and hide or show them as required or have an empty placeholder panel and use a factory to construct the appropriate UserControl as needed. I've done both and it really depends on the complexity (and expected longevity and users) of the project as to which is appropriate.
Using a Model-View-Presenter pattern helped with managing all of this.
What you don't want to end up with is a massive switch statement that changes the visibility of dozens of manually positioned controls individually. I've seen it and that way lies madness.
I am trying to create editable tree widget. There are many samples how to make editable columns for Table, for example by using cellrenderer and propertyCellRendererFactoryFunc - which is quite awesome. Unfortunately I can't find any useful example for VirtualTree/Tree. Is it even possible to create one without deep Tree source code editing?
Here is one approach for VirtualTree:
VirtualTree uses normal widgets for the tree items, so the idea is to taylor the way these items are created, in order to modify their appearance.
This is achieved through a delegate. Use tree.setDelegate() to set a custom delegate on a tree.
The delegate itself can be a native JS object (map). It has to conform to the IVirtualTreeDelegate interface, meaning the delegate object exposes some methods from a predefined set (like 'bindItem', 'createItem', ...). See the code of this demo for a general example.
In your case, you want to provide a createItem method in your delegate, along with any other supporting methods (e.g. bindItem). There is a somewhat more complicated example that does that, which uses an instance of itself as the delegate.
HTH
I'm writing a WPF application while mostly adhering to the MVVM design pattern. The application has various educational modules broken up into different categories to be accomplished by the user. The modules are organized into a hierarchical menu. My ViewModel has a class called MenuPageViewModel which exposes the information needed to render a MenuNode. Naturally, the terminal elements in the menu tree have content that I'd like to display to the user. This content can be one of many different types of modules. Currently, when the user selects a module in the menu, I can't see any way around using a large conditional block to determine what type of ViewModel I'd like to return to be displayed based on the type of the MenuItem's Content Property. For example...
if (CurrentlySelectedMenuItem.Content is Lesson)
return new LessonViewModel(CurrentlySelectedMenuItem.Content as Lesson);
if (CurrentlySelectedMenuItem.Content is SkillsCheck)
return new SkillsCheckViewModel(CurrentlySelectedMenuItem.Content as SkillsCheck);
Can someone give me a hint to a more elegant and maintainable approach? Right now, if I add a new module type, I have to remember to update this conditional block, and that just sort of annoys me.
Thanks.
If you are using Unity/Prism then using the container to resolve the object would be my first preference.
_container.Resolve(Type.GetType(strObjectType)) as BaseViewModel;
where strObjectType is a string with the type of class you want to create (eg "LessionViewModel" )
if you are not using Unity, then reflection works
Activator.CreateInstance(strObjectType) as BaseViewModel;
with both solutions you need to have the string with the class type on your menuItem.
A third option is to have a factory, but it would probably end up having a conditional situation within it or will contain the code i just listed.