Edit: A simpler phrasing of this question would be...
Can't I build a full fledged enyo app with readable code while only using Controls to take the place of Components, Kinds, Models, and Collections?
..
I'm learning EnyoJS and I have yet to find a clear comparison between Components, Kinds, Controls, Collections, and Models.
I understand that for example a Control is a Component that by convention refers to a visible DOM element that the user interacts with directly...but so many of these differences among the aforementioned types seem to be by convention rather than enforced by the framework. It seems that any given idea can be expressed as a Component or a Collection or a Model or...
Can you clearly explain the API differences between these types?
Can you show how certain functionality is truly missing from any one of them but present in another?
Wow. That's a big question.
With regards to controls and components, it's not just convention that differentiates the two. Controls are an Enyo Kind that inherits from the Component Enyo Kind. Controls actually contain methods and properties (specifically for dealing with the DOM) that just don't exist in Components. They're not interchangeable.
The documentation on the Enyo web site does a very good job of explaining the difference between Kinds, Components and Controls.
http://enyojs.com/docs/2.4.0/
There's also the API reference, which breaks out for you the various properties, so you can see for yourself all of the properties that exist (and don't exist) in Kinds, Components and Controls.
http://enyojs.com/docs/2.4.0/api.html#enyo.Control
And finally, since Enyo is open source, you can look at the actual source code to see the differences.
Collections and Models are fairly new to Enyo, starting with Enyo 2.4. Their job is to hold data (A Collection is a group of one or more instances of a Model). Models usually contain JavaScript or Enyo Objects, not Components or Controls.
Components make up the skeleton of your app, Controls are the UI for your app and Models contain the data for your app.
Expanding a bit on Art's answer: You can certainly build a fully functional and maintainable app without Models and Collections. Those kinds help with the data binding infrastructure in version 2.4. If you don't wish to use those features, you can build on version 2.2 and only use Controls and its subkinds (e.g. enyo.Input).
Regarding Components, you could easily build an enyo without creating your own Component but you can't avoid using them because it's part of Control's prototype hierarchy. As Art said, the difference between Component and Control is more than convention. The Component kind facilitates the composition of instances of components. Control extends that to support rendering into the DOM and its containment hierarchy. See post from my Enyo Daily series for some (slightly dated) details.
More concretely, if you don't need to render anything into the DOM but you want to encapsulate some logic into something module-like, use Component. If you need a DOM node, use Control or one of its derivatives.
Related
The project I'm working on calls for workspace layouts for a large section of it, by which I mean that users can move around panes, resize them, close them, etc., like in VSCode (but more like Emacs since VSCode does not currently support both vertical and horizontal splitting).
The current methodology I'm considering to create a custom LayoutManager that has a json object and injects views into recursive Row and Column objects in a binary-tree-like structure. Before I start this undertaking, I'm wondering if there is a library or set of QtQuick (QML) elements that would let me do this a lot more easily or if there is a better approach to this problem. Or, please just tell me why I'm wrong in doing it this way.
Note: The technologies I'm using are C++ with Qt 5 (currently 5.10).
If you want highly customizable GUI, with the option of persisting UI configuration, it is best to design the whole thing model driven.
QML already has the necessary stuff - list views, repeaters and so on. QML is a little at odds with tree models, but you can essentially fake a tree by using lists of lists.
The model provided here will do the trick, with the added benefit it also supports declarative instantiation. So you can easily set up an initial GUI state declaratively, like you would with normal QML, but then allow the user to make modifications to that initial state which can then be saved and recalled.
Then all you have to do is bind the desired GUI elements to the underlying model data source objects.
Can you suggest me when to use states and when to use custom components? The advantages and disadvantages of using these too methods?
One problem I see using states in Flex 4.5 is, the includeIn property will be cumbersome if there are many states and needs to be set for individual container/controllers.
Thanks
Anji
Doesn't the use of states groups solve your problem and clarify all the combersome mess?
States and customs components are not hostile alternatives. They can be used together. It is not very clear form your questions what exact kind of components do you mean and why they solve includeIn problem.
You can refer to ActionScript and MXML visual classes as visual components. And one of the purposes of producing of such components is to reduce complexity. So if you have very complex states logic in some visual component (in MXML) it is very good to extract some subcomponents with corresponding states into separate components. These extracted components can be MXML components and can contain states with includeIn/excludeFrom logic. Or they can be ActionScript components with skin states.
States and extracting components can live together easily. One of developer's main goals is to reduce complexity. And common sense is the best weapon to do that.
I think I'm overusing the Flex states model. The way the Spark architecture teaches it, states should mainly be used for changing the visual appearance of a certain component. However, being overly excited about the simplicity of using Flex states, and also willing to reuse existing object instances at runtime, I made my components really "thick", injecting different view models, as well as other stuff, based on a certain state change. This created a bunch of problems with synchronization, so I decided to subclass and specialize instead of relying on states that much.
In general, as a rule of thumb, where should the boundary between states and subclassing be put?
Well, from what I understand, you have a huge view that you now want to use inheritance to split it up? Won't that still make your component heavy and hard to manage?
The better solution here is to use composition, not inheritance. Create new, self-managing and small components that come as a whole into a larger one. There really shouldn't be a 'boundary between states and subclassing' because they do 2 completely different things. One is for view based changes while the other is to add functionality.
I think you're just really mixing up your OOP concepts and should really stop what you're doing and go over the theory a bit before continuing. If you continue on your current path, you'll end up where you're heading; spaghetti code.
I'm currently implementing a project using asp.net, c# and the MVP (Model-View-Presenter) pattern. The main purpose of this solution is to deliver a graph to the consumer, to be used by a variety of systems. It is basically a custom graph server.
The view page in this particular case has an MSChart control on it, which has to be dynamically populated and configured based on parameters in the QueryString. This can be as diverse as totally different types of data sets, display modes and so on, using a lot of the properties of the chart control.
Many of these properties are again of types which are particular to the chart control and would require the same dependencies as the chart control itself if they are to be set by the presenter.
I'm trying to figure out the best way to expose the properties to the presenter so it can work its magic.
Should I:
Just expose the whole chart object and live with a system.web type dependency in the presenter project?
Make accessor and translation properties for all of the chart control properties so that I don't have the dependency, but add lots of complexity?
Other, that I haven't thought of?
To me it seems that it would be against the MVP pattern to bubble a display control up into the presenter, but it seems that trying to map all the properties to DTOs or similar would be a lot of work that would add a lot of complexity, and while the solution would be somewhat more loosely coupled, I'm not sure the gain would be worth it in this case.
How would you implement something like this, given MVP?
While doing some more research on this topic, I found the following blog post on adding a Presenter Model to handle complex view controls, to map between the view and the presenter. It actually made a lot of sense to me, and it's an idea I think I'm going to follow up on and try.
http://mikewagg.blogspot.com/2009/01/managing-complexity-with-mvp-and.html
In fact, Martin Fowler has written on this as well:
http://martinfowler.com/eaaDev/PresentationModel.html
Check out Automapper. Makes translating from a Business Object to a View Model almost effortless. The general idea is your View Model should only have primitive system types if possible to avoid formatting/conditionals in your view.
I have an ASP.NET web site dedicated to reporting on PBX extension stats. It comprises many report pages, with HTML generated almost purely by code-behind (setting a Label control's Text property instead of using Response.Write), using un-parameterised string literal SQL queries that populate By Reference DataTable parameters.
Maintenance pages at least comprise DataGrids and detail forms, but use the same DAL, on e thing for which can be said is that it supports multiple DB servers, with sub-classes each overriding these access methods with their own string literal queries.
What do I need to consider cleaning up this mess? I've already made an almost obvious decision to use a third party reporting solution, and move the queries to stored procs in their respective DB languages, narrowing the diversity of the different DAL classes, and to separate CSS out to shared files, as lots of it is very hidden in C# files!
For your back-end design, I suggest having a class to represent each main table of your database (i.e. a Report class and a User class, for example). Anything that's not an event handler should go in the back-end class files / namespace.
For your GUI, looks like you're on the right track using ASP.NET controls instead of just streaming your data out to the user. However, you may consider objectifying the areas of the page. For example, one of my favorite tricks is to open semitransparent "popup" panels when requiring user input or a something like the Information Bar when displaying a short message.
Consider AJAX and the AJAX Control Toolkit. It's easy to implement (especially in the case of a rewrite) and provides great flexibility. Specifically, I've found Accordions - sometimes even nested within other Accordions - are excellent at organizing overabundances of information.
Edit:
Note that if you were to use AJAX, you basically can't even consider using response.write anymore.
As far as having too much content on the screen, remember Panels have a "Scrollbar" property and DIVs don't without some heavy changes.
Also, I tend to separate my code files by Namespace; but the popular trend is to do so by Class. This is a better option if you have many Developers or if it's likely several classes within a namespace will be checked out or simultaneously modified by different people.
I would consider ditching any custom written DAL and use one of:
iBATIS.NET
NHibernate
SubSonic
You might even end up dropping sprocs entirely.
If you're daring you could try the redesign using Microsoft's MVC implementation.
Whatever approach you take, make sure you write unit tests prior to refactoring any code, verify the tests pass before and after refactoring.