Hello and happy new year :)
I have a question about the development of a component and in this case now for the site. In the backend I have everything ready.
I have a Component->Model->view (formcheck) which contains several layouts:
default.php
one.php
two.php
finish.php
The basic data from the DB is displayed in the default layout and the user can specify additional data. At the end there are two buttons (one and two), which call the corresponding layout (one, two). In these two layouts the user can enter further data, which are then processed. With the button "finish" the last layout is called. In the finish layout, the data is finally processed and only stored here in the DB.
The data will be stored in the session until the end and only after processing in the last layout will it be stored in the DB.
The user can only go one way at a time default -> one -> finish or default -> two -> finish.
Currently I have the logic (get session-data, process, save session) in the layouts. But I wanted to outsource this better, because layout and logic are separated. But where do I put the logic and how do I call the layouts?
In my thick joomla book there is unfortunately no such thing. :(
P.S. The forms in the views are without form.xml, because the layouts are structured differently.
Related
I am currently working on a project in ServiceNow that requires me to configure around 500 descendants of the Configuration Item table by adding multiple form sections to the CI's with around 10-20 fields in each of these form sections. I currently am doing this by going into the Form Design for each CI, and manually adding these form section and fields for every CI individually, which takes far to long to do for 500 CI's.
Is there a way to add a form section to multiple CI's without having to go into the form design on every CI you want to change and adding it manually?
Technical answer: yes, because all of that form layout data is stored in tables (sys_ui_form_section, sys_ui_section, sys_ui_element, etc) that you could script to insert relevant records. However, due to the complexity (form sections, form elements, ordering) and the potential to run into conflicts (forms differ between tables), I would recommend this only as a last resort.
I think the real question is why is it required to have all of those fields displayed on the forms? If you're populating data from Discovery or a large import, can those fields just be visible by a list page, or just be available to use in filters? Will users actually be clicking to view a CI record and need to see that data on the form? The other part to consider is which view you are adding all of these form sections and fields to. As an example, a user won't see the data on a reference field hover if you're only making changes to the Default view, and won't see any of the fields on a mobile device if you don't add to the Mobile view.
Good day, I am quite new to windows phone and so please bear with me. I have a requirement to load a XAML layout based on what the user chooses. For example, if i have 4 XAML layouts A, B, C, D, when the user chooses C, the respective XAML layout should be loaded and if A is choosen later, that should come up. I can create different XAML layouts and use the OnNavigateTo Method, but i think its not very efficient. Is there a way, i can group the XAML Layouts together so that it can switch between them easily?.. I have heard of using templates, but can't really find any concrete example of how it works. Any help or links will be greatly appreciated. Thank you.
From my understanding you do not need to use templates. Since there are four different actions that have four different views associated with them, there shouldn't really be a problem with having a separate page for each action.
The problem might also be this - how different are the layouts? If data is the only thing that changes across them, you might think about having a view model to bind to and simply change the bindable source.
Bottom line: just use pages, or a single page bound to dynamic data, depending on your scenario.
In my knowledge , I ask you to prefer the UserControls implementation in your UI. You can have A,B,C and D layouts as a separate UserControls and can have those UserControls in the same page. Just make the visibility changes based on the condition that recognize it in the code behind. I think it may help you.
You can solve this in many different ways. If you are not supposed to load the layout on the same page, create 4 separate pages for each view and navigate to correct page.
If you are required to update the current view, you can choose one of the following:
- Place all four layouts into each own Grid and set Visibility="Collapsed" for each one. Then, when you need to show a layout, simply change its Visibility to True.
- Same as above, but use Visual States to add some animations.
- Create 4 user controls and dynamically create the one you need and add it to the current page.
You need to account for several factors here:
- Clean code and clean design.
- Animations and transitions.
- What about Back key? If user is supposed to navigate back to selection screen once he is done, consider navigating to separate pages.
Don't forget the last point, it may be crucial when choosing the right solution.
I have a form with tabs related to a business entity - e.g. a Person has biographical data, address data, etc. Each tab handles input/editing of a category of Person data, and each tab can be saved independently. Should one presenter be used for all tabs, or one presenter per tab? There may also be a main tab, which can navigate to the other tabs (based on category of data selected).
I create one presenter per view. If each tab is a separate view, then each tab would have it's own presenter.
In my opinion the logical thing happening here is that you are working with the data of a single person. It is incidental to the presenter whether the UI i.e. view is using tabs, a spreadsheet, or a unified list of entry controls.
The view should have the responsibility of of switching between tabs, sending data from the presenter, and placing the data the presenter gives it in the correct places.
The presenter takes the data the view sends it and does whatever validation is needed and stores it. It is also responsible for updated the view when new data received.
This way if the tab interface doesn't work then it is easy to switch by having the new UI implement the view interface.
If it is important to updates only one tab then the presenter can be design with the concepts of categories. As part of the logic of the presenter it tell the view to update only one category of data.
On a unified entry form this will manifest as only one section of the form updating. On the tabbed form that you mentioned in your original post, this will result in one tab updating.
It is important to strike a balance between the number of classes and their functionality. To few and they are doing to many things that will be hard to separate in the future maintenance. Too many and it will become confusing as to their relationship again complicating future maintenance.
I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.
Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.
Thanks in advance for any guidance!
My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.
This will avoid inheritance, make your code more robust and testing of forms possible in isolation.
My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.
This is my first time building a UI in Access (using Access 2007), and I'm wondering what is the Right Way (TM) of going about this.
Essentially, I have several different queries that I'd like to display as pivot charts, pivot tables, tables, and reports. Eventually I'm also going to have to build forms to manipulate the data as well, but the application's primary function is to display data.
I'm thinking of having a button for each different display down the left side of the main window, and having the rest of the window display each button's corresponding contents (e.g. a pivot chart).
I have an idea that this can be accomplished using a single subform in the main form, and setting the subform's Source Object property within a function such as this one:
Public Function SetSubformSourceObject(newSourceObject) As Variant
subform.SourceObject = newSourceObject
End Function
Then, for each button I'd set its OnClick property to call this function with the name of the query I'd like to run.
Now, I have no idea if this is the best way of going about things, and would really appreciate some input :)
The principle seems fair to me. You have to give it a try. You do not even need a form-subform structure. You can set your sourceObject at the form level, and have your buttons in a commandBar instead of having them as controls on the form, so you do not have any 'form specific' code (like "onCLick") and controls. action/command controls on a form are space, code and maintenance consuming, while commandbars are more generic and are THE object that can hold all your action controls.