Those are three concepts on Yii that I really don't get what should we use, on what scenarios?
Can anyone be kind enough to clarify those Yii elements, and on what situation should we use them?
In documentation of CForm one can read the following:
...we can divide a form
in two parts: those that specify each individual form inputs, and
those that decorate the form inputs. A CForm object represents the former part...
...and CActiveForm represents the latter.
In other words, CForm specifies elements of the form but CActiveForm (being a widget) renders it.
Looking at the source code we state that CForm can also render() itself and its rendering relies on and is wrapped by CActiveForm widget by introducing its configuration property activeForm, though rendering input elements and buttons is implemented by its own methods renderElements() and renderButtons() relatively. By default their implementations rely on classes using CHtml's static methods what is exactly the same (or almost exactly the same) what CActiveForm's rendering methods do. Of course, default behavior can be overriden by extending the class.
That's why it's the question of a taste which technique to use: CActiveForm widget alone combining form fields' and buttons' declaration with their representation in a view file by calling convenient (required) methods of CActiveForm instance or CForm class declaring form's input specifications in a separate configuration file and customizing its rendering by pointing at appropriate active form widget and/or by overriding default rendering methods. The latter technique allows to reuse a form in several actions easily and is no more than using form builder.
Check here for live examples of ActiveForm, CForm, et cetera. You can also see the live Model, View & Controller files.
Related
I am trying to model a part of my VUE app with UML. I used a class diagram to show the structure and a sequence diagram to show one specific behavior.
There are some things I am not sure about:
in regards to the class diagram: the Form copmonent imports the data criteria, whos criterium is passed to the child and the option to the grand-child. So each instance of the child FormItem holds one criterium of criteria and each instance of the grandchild BaseRadio holds one option of the options array. So the data flow is through the parent. Can I still relate criterium - FormItem and option - BaseRadio as indicated by the blue composition arrows?
in regards to the sequence diagram, my aim is to visualize the cross-component data flow and custom event communication with emitting events and passing props. I sketched these as synchronous messages, since they don't return anything but this feels weird?
are the functions called within one component supposed to be reflexive messages? (as shown in the sequence diagram for setoption(option):void for example). And I guess the presentation of computed properties integrationChance and integrationProspectPercentage as reflexive message is wrong, since they dont represent functions?
Here, the draft of the UML class-diagram sketching the VUE app:
And the sequence diagram:
And here the description of what this app does:
The data for the function is imported as a JSON Object criteria.
For each criterium (e.g. gender, age, etc.) criteria holds an object named criterium, which has a label and an array options. The options array holds an option for each attribute (male, female, etc.).
Each option has a name (e.g. male) and a correspondent value (e.g. 0).
The Form component imports the criteria object and two other components: FormItem and FormResultBar. The Form holds only one FormResultBar. For each criterium in criteria the form holds one FormItem and for each option the FormItem holds one BaseRadio button.
When the user clicks on a BaseRadio button, its computed property selectedValue emits an event to the FormItem, passing the value of the option that was clicked and the correspondent criteriumKey.
The FormItem component then sets the selected option (setOption()) and saves it (saveOption(option, criteriumKey) by emitting an event to the parent component Form and passing the parameters option and criteriumKey. In the Form component the saveOption(option, criteriumKey) saves the selected Option by storing it in the selections Object.
The selections Object holds all the selected options for each criterium. The computed property integrationChance in Form item then calculcates the integrationChance by adding all the values of the options stored in selections. The method integrationChancePercentage transform the logisitic regression value into percentages. The integrationChancePercentage is then passed as the prop “result” to the FormResultBar, where the result gets displayed.
You can find the implemented part of the application here.
The key question here is not whether UML is suitable for the job or not, but what do you want to show in your diagrams:
In this other question I have developed what relevant diagrams could be used for in a JS context with Electron. I think it may answer your question about which diagrams to use.
You have opted for a class diagram. It explains well the the internal structure based on classes and their relationships:
A Vue component can be represented by a class:
Components are reusable Vue instances with a name (source: Vue guide)
props may be shown it as an UML property:
Props are custom attributes you can register on a component. When a value is passed to a prop attribute, it becomes a property on that component instance. (source: Vue guide)
UML classes are usually represented with a box with 2 separators. The first part is the class name, the second part is for the properties and a third part are for operations. Since props can be accessed from other components, it seems better to give them a public accessibility in the class diagram (+ instead of -)
Computed properties could be shown as derived properties, i.e. with its name preceded by /:
(...) its value or values may be computed from other information. Actions involving a derived Property behave the same as for a nonderived Property. Derived Properties are often specified to be read-only (i.e., clients may not directly change values). But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property. (source: UML specifications)
Your “methods” are operations in UML,.
I’m not a Vue expert, but I understand that “watchers” seem to be some special kind of methods.
More generally, I'd suggest to use a custom UML profile for Vue. It may define stereotypes for each of these kind of elements (e.g. «Vue component», «props», «computed») that would precede the name of the element or be above it. This could convey a more precise semantic, especially if there could be ambiguities (e.g. methods vs watchers).
Your narrative explains the interaction between components. This is best documented with a sequence diagram. Lifelines would be instances of components or props instances of a component, and messages exchanged between lifelines would correspond to Vue methods, and other means to exchange information.
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.
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 CForm which is instantiate in a controller. Now I need to use some widgets as its element, even by validations and more capabilities.
Who to do that?
Validations are something that belong into the realm of the injected model. It is not the duty of CFormto perform any input validation/sanitization.
As for widgets, see this part of the guide. Just before the section "Specifying Static Text," there is a whole bunch of informations on how to integrate widgets extending either CInputWidget or CJuiInputWIdget.
I need to know if I am going about something the right way.
For a given page, I am instantiating an object for the page itself. Let's call that object myPage. Within the page I have containers (usually div tags). When I go to an admin component to work with a specific div, I instantiate an object for that as well. Let's call that myDiv.
Now, one of the things I want to work with for a given div is the styling of that div. So normally I would think that I'd just put in some style-related methods, such as myDiv.getPadding() or myDiv.getBackgroundColor(), etc.
But it occurs to me that I may eventually have other objects for which I may also need to do style-related stuff.
Given this, should I then create a separate style.cfc? Would that then be extended by the div object? Or would the style object extend the div object? My understanding is that the more specific object extends the less specific one, but I am not sure which is more specific in this case: is it the div object, which references a specific div, or the style object, which provides a specific set of data?
Thanks in advance!
First, unless you need to write styles on-the-fly, I would create one or more stylesheets and link them dynamically, instead of creating them dynamically.
Assuming, however, that you do need to create them on-the-fly...
I would not have either the control (div) extend the style or vice-versa. A style is not a more specific definition of a div, nor is the reverse true. What I would do is create a style object that only contains the display meta-data for a given element or element set. This can be contained within your control/div object (not an extension), or can be part of the page object. The style is definitely related to the control, but I would not combine them, as that makes it harder to separate content and presentation.
By no means am I saying this is the best approach, but if you really wanted to use CFCs to style your pages, you could have a DivTag.cfc extend an HtmlTag.cfc, which would act as your base class for all HTML tags. You could then compose a StyleAttribute.cfc into your HtmlTag.cfc to work with any style properties, such as background colors and padding. So then you would end up calling functions like myDiv.getStyle().getPadding().
In general, you should really try to favor composition ("has a") over inheritance ("is a") and not get too crazy with your component hierarchies. In this case, I'd recommend using CSS files to style your pages.