I have an elm app designed with the Elm Architecture in mind. I've used it for all the samples in the tutorial and they work fine. I have the following components
ContainerListView
ContainerView
AddressView
RegistrationView
...
The ContainerView component is a very formatted div structure that is used to contain other views (but for now, only 1 at a time)
ContainerListView can contain multiple containerViews. It handles their presentation and positioning. You can think of it as an MDI surface
A menu from the main ui is used to add new container views to the container view list.
I'm presented with with three main questions. Two of them are
How do I create the components such that Container view can contain any other element is I pass in for example the init, update, and view functions and expect all things to be wired correctly? At the moment, the samle views I have are kinda hard-coded. They know exactly who the children is.
Some of the components require access to things like url, access token, etc. Does this always have to be passed in from main to the individual components or it can come from another source which will essentially be readonly and maybe updatable only from main?
I'm not sure if these two should be individual questions on their own. Any information on how to architect larger apps beyound hello world will also be appreciated.
I'm working on something similar! Nested controls. I too have a container object which knows about all the types that it can handle, and has basically case statements to handle each type. So I can't drop in a new control type and expect it to handle it, that requires altering the container.
As far as I know elm doesn't have type classes, which would be how I might try to handle that kind of abstraction in haskell or purescript. There's more about that here:
https://github.com/elm-lang/elm-compiler/issues/38
and here:
https://github.com/elm-lang/elm-compiler/issues/1039
The upshot appears to be that they don't know how they want to solve that problem yet, so they haven't.
Related
I'm writing an app in Vue and I have a really hard time understanding the component hierarchy, namely the parent-child relationships and how to pass data around.
I have a view that contains a map which in turn has some navigation controls and options that are overlayed on top of the map. Now, I want these controls to manipulate the map WITHOUT having to nest the buttons inside the actual maps as it will cause severe display issues (for example, clicking on a zoom button falls through the button and also clicks the next element under it).
My app looks like this:
Mapview
Map
Controls
Options
Optionpanel1
Optionpanel2
...
Now, a HTML input element in Optionpanel1 needs to control something in the Map, which is not actually it's parent component. Also, some data from Map needs to be passed down to Optionpanel1 so it would know what to control. To make matters worse, something in Options also needs to pass something down to Optionpanel1, so, even though event bus would allow communication upwards, it would not solve that I need to pass data from parents to indirect children and also components that are not it's children.
I can actually pass the required property down the line if I nest the Options inside Map and pass it down with :myProp="prop" and then in Options, declare it in props and bind to Optionpanel1, where it is again declared as a prop. But as I mentioned earlier, nesting elements that I do not want to be nested in a visual sense causes massive issues like mouse click falling through. Do elements even need to be nested inside eachother in order to define parent-child relationship?
I would want components to exchange read-only data without Y being a child of X in the DOM. Also, even if nesting components like this would not cause visual issues, does it not seem very annoying to have to register and bind it in every component along the way?
I don't understand why is it so difficult to simply read something from another component. It's starting to seem that Vue is causing a problem that it's supposed to solve? Am I missing something here or am I looking at this in a completely wrong way?
Thanks in advance.
Basically you have 2 options to control complex components:
Handle the actions in your so-called "smart component" (in terms of React), which is the common ancestor for the controlling and controlled components. It's a pretty good solution for small components, but that's not the case.
To separate common logic and data in a Vuex store. I'd recommend you doing this.
Trying to implement the layout of the picture below, I would like to ask about best practices regarding the architecture of the page layout. Is it better to have independent ViewComponents in every section of the page or partial views? Is it possible to have nested ViewComponents?
The idea is to reuse the sections in other positions in different pages. The concept is very similar to Web parts we used to have but now I try to implement something like this with Asp. Net Core.
Yes, it is possible to have nested View Components.
What is important to keep in mind:
You should keep your views structure under Components folder plain
You should keep your ViewComponent classes under ViewComponent folder plain
You should control infinite loops yourself when you nest component1 into component2 and at the same time component2 into component1
NOTE: most likely you will need your components to include edit/save/update functionalities. As far as I understand, View Components are supposed to be views only as they have only InvokeAsync and not something like UpdateAsync. So if you'd like to implement any kind of saving logic, you will need to take care of doing this yourself (e.g. via AJAX calls). It is possible (I have verified), but it requires to get familiar with Microsoft.jQuery.Unobtrusive.Ajax and handle responses on the client side in JavaScript (sometimes including things like replacing in JS the DOM element inner HTML with what you get from the server response). You will also need to decide where to put controller actions for view component update endpoints (could be a special Controller class for View Components).
If a button is optionally shown on a page (or part of page), does it qualify that part to be represented as two different PageObjects, where one PageObject provides methods to interact with the button while other PageObject does not? Or, should it be one page with a method which can throw an exception when the Button is not rendered.
What will be a maintainable solution - because in future releases the button may start appearing in both cases or the functionality may totally change.
In this case
the button may start appearing in both cases or the functionality may totally change
possible solution can be - Transporter design pattern. It's basically - navigation that aggregates reused page objects in one external object. Also centralizes the navigation control in the tested system according to the test requirements. This object encapsulates logic associated with the implementation of navigation within the tested system. Thus the problem of business logic does not interfere with the navigation within the system.
I think that Composite Page Object is acceptable and
maintainable solution
in both cases. Since It will allow you to structure your Page objects in a more “object-oriented” way by separating sub objects that can be reused on different pages and include them into the parent object. Consider this example:
Further reading about GUI automation patterns.
I have a qml app which is created via two separate ways.
1) via a c++ code during startup
2) via my main.qml as one of the tabs.
Inside the qml app I want to know who is my parent so that I can decide if I should stay on my current page or load some other qml. How to know who is the parent to take such decision?
This question is difficult to answer for a few reasons. Notably, it's not especially clear what you want. The simple answer to your question is that a QML element always has access to it's parent via the exposed parent property that exists on all objects. If your question is more complicated as it appears then you need to rephrase the question to better clarify what you actually want.
I have a listener that is called when a tab is activated.
, listeners: {
activate: function(tab){
var first = tab.down('input'), // will be null
firstEl = tab.getEl().down('input'); // will contain first input element
I'm not having a lot of luck understanding the relationship between tab and tab.getEl(). If this was jquery, $(tab) would give me a jquery element which would largely expand on my set of options. extjs seems to be almost backwards in this regards, or at least more complicated.
I'm trying to understand when and why I need getEl() so that it is less of a development crapshoot about what will and won't work. In other places I do things like:
showFieldHelpOnBlur = function(ctrl) {
ctrl.up('form').down('#helptext').update("");
}
without the getEl(). In this case form is an element tag just like input (above), but I don't need the getEl() before I use it. In general the two sets of functionality that share the same names but don't work the same are frustrating, and the docs don't seem to give any clue as to why there are multiple methods with the same names that do different things, or do similar things in a different way.
Found some similar issues with focus(), but those might make more sense if I just understood why are there are 2 seemingly parallel sets of methods for what are essentially DOM elements wrapped in additional functionality.
I think at the core of your confusion is how you approach the development using ExtJS vs JQuery.
JQuery is all about DOM manipulation and low level API. ExtJS approach is very different, it wants you to think of your page structure as a hierarchy of ExtJS components that are responsible for rendering appropriate HTML. So ExtJS is essentially saying: "Don't worry about html, we'll take care of it - you focus on the larger components, layouts, events, etc. "
You will say "Whoa Nelly! What do you mean don't worry about html? I want control!" And ExtJS will respond OK - we have a wrapper object called Element (http://docs.sencha.com/extjs/4.1.3/#!/api/Ext.dom.Element) you can use it to do DOM manipulation just like you are used to with JQuery .. but be cautious. Because if you manage your own HTML we can't be responsible for what happens to your layouts and components that are not managed by the framework.
My advice is this - when in Rome do like Romans do :)
If you are going to be using ExtJS to build apps - embrace the way ExtJS is designed to work. Learn the different layout mechanics and numerous component types available to you out of the box. Use the MVC development pattern to beautifully organize your code. Use the examples to your advantage. Study the architecture and component guides - these are very useful. Understanding ComponentQuery class is a must (all those up/down methods and query).
At the end, when you have gained comfort using ExtJS components and their style of development you will be very efficient at building your UI compositions and can build much more complex applications than before.
Good Luck!
Pro Tip: Do yourself a favor and get Illuminations for Developers plugin for Firebug - it will open your eyes to see things using component structure rather than HTML elements.