I have a use case where users can register themselves. Once registered, the users become "members". There is a Skyve document describing "members"
As part of the registering process the registering user pretty much needs to enter all the information on the "members" document.
I have a registration document describing the registration process, it has a few steps, one of which is to enter the users information. I have an association to the member document in the registration document. Is there anyway of re/using the original member documents create view?
You can use a bound view component to achieve this.
See https://skyvers.github.io/skyve-dev-guide/views/#view-components
<component binding="member" />
will inline the Member document view (create or edit depending on the whether the underlying bean is persisted or not).
You can also name the view component for the target document the binding references to make things explicit.
<component binding="member" name="create" />
Related
is it possible (and if so how) to route the MODEL exception messages to be presented on the JSF page and NOT in a popup?
scenario:
JSF page contains master-detail tables
when a user clicks on a row of the master table, there are some operations (Iterator+ExceuteWithParams) executed in the detailImpl.java (by prepareRowSetForQuery(ViewRowSetImpl vrs).
some of those operations can return exceptions from the DB. we don't want those exception messages to be presented as popups, but instead to be shown inside the JSF page in a certain place that will be used for those messages (Ex. af:outputText). the component needs to be updated with the new error every time it was thrown from the model
how it can be done?
examples please
try experimenting with 'af:messages' component.
I created an object that is backed by a Foundry Form and I would like to provide a user to change the properties of that object. I linked the form to the object and created a title property that is a hidden/ derived value in the object creation form. A user can edit property a and property b and the title of the object will be ab.
When the user updates the object in the edit form the title does not update. Is there a configuration I need to change?
Yes, this is possible. There's actually two ways to achieve this, I'll list them in order of my preference:
Using an action
The modern way of achieving this is to use an action. Actions allow you to flexibly "intercept" events like writes from users and do extra actions (hence the name) or prevent things from happening. They are a fairly new feature in foundry.
The basic concept is that you write a little piece of code (a function on an object) that gets executed when the object is modified. The function can then modify the object further or prevent the modification.
This is very flexible, because it will allow you to automatically update the title of the object regardless of how and when the object was edited. You can also apply more complex logic to derive the title from e.g. multiple properties with fallbacks, or modify a property in a certain way before you put it into the title, et cetera.
The drawback is that this requires you to write some code.
On your stack, if you navigate to https://www.palantir.com/docs/foundry/functions/use-functions/#actions you will find an introduction on how to get started with actions. The example solves the exact use-case you're asking for.
Using form templates
Another approach that's simpler and does not require writing any code, but is much less flexible, is to use a template in the form. You can create a template form widget that's invisible, and is automatically populated by values from other form fields.
The advantage is that this is very easy and quick to set up, but the disadvantage is that it will only apply when the object is edited through the form, and you can really only do concatenation, not much else.
It sounds like this is what you attempted to do, and I believe this should work. If it doesn't, I would check the following things:
make the template visible to see that it gets filled out like you expect it to
make sure the template is set to store its response into the right property on the object
make sure the user is using the form to edit the object, not some other way (like editing the property directly in hubble)
Lets say we have a Rest resource that looks like this:
{
"orderId" : 123
"details" : [
{"detailId":555,...more attribs},
...more details
]
}
In my view, I want to hold extra state for the order details, eg. isHidden, isExpanded etc.
I could add those to the detail object once the resource is fetched from the server.
But that would make those view specific properties go along with the resource when I post it back to the server to save it.
Making the json deserialize on the backend crash..
I've experimented with view specific properties that start with $$, which angular will remove when it jsonifies the resource.
That works, but those properties are not included in the digest cycle so changing those doesnt trigger an update of the view.
I've also experimented with nested controllers and keeping those view properties in the detail controller.. which works fine..
That does however make it harder to set up the views when the resource is loaded, I can not modify those view properties in the root controller since the details does not yet have a controller assigned to them..
Another posibillity would be to wrap the resource in a specific view model that keeps these properties. but that requires a bit more coding and mapping.
How do you guys deal with this kind of problems??
First off, I've done a lot of research on the web (including this site) and have found lots of conflicting information on how the model and controller communicate in an MVC pattern. Here is my specific question (I'm using AS3), but it's a general MVC question...
I have two main components... a list of recipes and a form that displays a selected recipe. The form has an edit state that allows you to edit the recipe and then save or cancel the changes. What is the best way (using MVC principles) to handle changes made to a recipe? So far, I have the save button trigger an event which is captured by the controller.
Should I have the save button (the view) pass an object with the current state of the fields along with the event (some logic in view)? Should I allow the controller to hold access to the view and have the controller figure out what's in the fields on its own (added coupling)? Should events be made every time a field in the form is changed and the controller keeps track of the state of each field (lots of events)? Or is their another way? Note: I don't want to bind the fields to the model because I only want the data to save if the save button is clicked.
Any help would be greatly appreciated. Thanks!
Should I have the save button (the view) pass an object with the
current state of the fields along with the event (some logic in view)?
yes, this is not 'logic in the view', it does not decide anything, simply reporting an action and its current state
Should I allow the controller to hold access to the view and have the
controller figure out what's in the fields on its own (added
coupling)?
no, this would become very messy, pass a VO with the event
Should events be made every time a field in the form is changed and
the controller keeps track of the state of each field (lots of
events)?
is an option, but this basically is the same as hitting the save button, the trigger is different (TextField.onChange), but you can dispatch the same event (setup is form = view, dispatches one general event with a VO, not an event for each field)
Or is their another way?
MVC flow w/ events:
onClick save btn: a RecipeEvent.SAVE is dispatched (from the view), with a VO (value object) containing the Recipe data (e.g. RecipeVO)
the controller catches this, and as the controller is where the logic resides, it decides what to do with it: update the RecipesModel (either directly by calling a method on the model, or by a custom event e.g. RecipeModelEvent.SAVE)
the model stores the data, and dispatches the RecipeEvent.UPDATE event (with the RecipeVO)
the views updated itself accordingly (check if the RecipeVO.ID is same, update data representation e.g. title…)
optionally, a controller could save the data to a back-end/remote database
As for the event listeners: views listen to the model, controller listen to the views.
About de-coupling:
use interfaces (by using an IModel you can swap out the model easily by another implementation, as you register the event listeners against the interface instead of the actual implementation)
Obviously, all this results in a lot of registering/removing event listeners, and keeping reference to the models/views/controllers to be able to register to the appropriate instance. An alternative is to use a framework as RobotLegs, as it makes a central event-bus available + easy/automatic cleanup of event listeners in the mediator class of a view.
I think this is really a database question. what I would do is create a stored procedure that first checks to see if the recipe already exists. If yes then update it. If not then add a new recipe. (you'll have to bind your entity to a stored procedure. other MVC frameworks can do this. I don't know about actionscript)
if that's not an option then I guess you would have to cache the original form in a helper class in the controller and then compare it to what the user is trying to save. And have the controller decide whether to update the recipe.
I think it's much cleaner to use the first way, but I've never used actionscript so...
Colin Moock's lecture on MVC in ActionScript is quite old, but still one of the best explications: http://www.moock.org/lectures/mvc/
Your model should populate your view, and your view should send input events to the controller, which should decide what to do with the input. As g10 says, wait until the save button is clicked and then pass an object with the modified fields up to the controller for processing. The controller can then decide whether or not to accept it, and whether to update an existing model object or create a new one.
I have a tree control in my GUI (with naturally lots of GUI/platform specific functions to handle the nodes).
I have a data model with its own complex set of nodes, children, properties etc..
I want the tree to display a representation of the model, be able to send messages to the nodes inside the model and be told to redraw itself when the model changes.
But I don't want the GUI code to need to know the details of the model's data types and I don't want to pollute the model by linking it to the GUI classes.
I can't get my head around how the controller is supposed to do this and what functions it should provide?
(this is in C++ but that shouldn't matter)
GUI "controls" don't quite fit neatly into a model-view-controller pattern because they typically have their own internal model rather than accepting a reference to one. If the control is structured that way, you'll need an adapter class that "data-binds" the control's internal model to the underlying data model.
This can accomplish something similar to what model-view-controller would, except that the adapter class plays the role both of a view hookup component (updating the GUI from the data model) and a controller (interpreting GUI events into model actions).
Qt provides a group of classes for model-view programming. You can hook a tree view to a filesystem model, for example, and neither directly know anything about each other (except a pointer to the model in the view).
Your requirements are:
Tree displays representation of model
Nodes in tree can send messages to nodes inside model
Tree redraws itself based on model changes
I don't know exactly what kind of data you're working with here, but a hierarchical model is a fairly simple thing. I'll take it as a given you know how to iterate hierarchical data and populate a tree view.
Your controller should have member function(s) for sending messages to the model. The parameters should be a model element and the message you want to send. This way, the UI is completely unaware of how the message gets to the element, but can get the messages through.
The last requirement is more tricky, and depends on a few things (e.g., the lifetime of the controller, application architecture, etc.) I'm going to assume the controller lives as long as the tree view does. If that's the case, then your controller should provide a way to set a callback on model changes. Then, when the controller changes the model, it can callback to the UI without being aware of the UI.
i think your troubles start with an unfortunate choice of words. the 'control' thingies doesn't have anything to do with the 'controller' in MVC. that's why some GUI libraries use other names (widgets is a common one).
your 'tree control' is the view, not the controller. it should be tied to the GUI, both for display, and to get GUI events and turn them into 'tree events'.
the controller gets those 'tree events' and does the necessary modifications to the model. that's where you couple the 'action' with the 'response'.
First Solution: You can implement a "Subject observer" pattern between model and view, with model as the subject and view as the observer. Whenever there is a change in the state of model, it can fire a event to all the observers those are registered, they can update themselves.
Second Solution: Introduce a controller, which registers with model as observer. Upon receiving a event for update from Model, it can update the view. Even you can decouple view from controller using one more subject observer pattern between controller and view
Third Solution: Use MVP pattern. Model view Presenter. This pattern used whenever there is no much computation in controller i.e., job of the controller is just to update its corresponding view. Here controller becomes Presenter.
You need a controller that sits outside the display widget but has the state of the tree (in MFc there are CTreeView/CTreeCtrl classes - there is a similiar separation in Qt) the tree controller handles all the data storage and calls redraws on the tree widget.
Changes in the tree widget get sent to the tree controller - so this controller needs to know about the gui functions.
The model will need set/get functions for all the relevant parameters for the nodes. But these can return simple types so aren't dependent on the gui.
Updating the view form the model requires sending a message, if you don't want the model to know about your gui messaging the best you can do is register a callback function (a void pointer to a function) from the tree controller - and call this to do an update.
This update function can then query the model for the changes.