This content has been marked as final. Show 9 replies
The only way you have to invoke an action from the applet is to use the getproperties call
inside the button, you will need to invoke the action through
say you want to implement the action related to Invoices
Property value = vueBean.getProperty("Invoices")
the return value is a Properly object than has a hierarchy (ie children)
it is a representation of the XML you filled on the DMS servlet side
We do not recommend you send XML per se, but if it is required, your data needs to be enclosed properly (cdata escape sequence) and you need to make sure
it will not be parsed during the decode of the info in the server (so watch out of parsing errors in the ISDK servlet and the server)
If you need an example of how to implement such an action on the servlet (isdk) you can take a look at the GetPropCSI_IntelliStamp.java class
to see how you can return complex data (or even a file)
once that class is implemented it need to be registered with the VueLink
by default it tries package.GetProp+name (in the example it would be GetPropInvoices)
it can be customized to load any class through
this is done through the connector servlet deployment descriptor file
add the dms.getprops.Invoices=mypackagename.myclassname
Hope this helped
That makes most sense, I need to put the knowledge into practice now though.
The example sounds perfect for obtaining information but lets say I wanted the DMS Servlet to perform an actual action.
Lets says I wanted to store markup notes that have been created in another database, is it possible to apply the same knowledge to implement a class that does something like ActionSave and call this from the applet button?
The thing I think I am missing here is how do I pass information back to the GetProp**** or Action**** class?
Thanks in advance!
I think I did something like that when customizing the Save Markup dialog. And it was a little nightmare to find the proper calls, but they are there.
In my case, I inherited the VueFrame to generate a dialog, and through its methods I could access the calls this way:
+// Update the frame's markup properties (redundant for an existing markup, yet harmless)+
mkProps = thisMarkup.getProperty();
+// Save the markup+
check = vueFrame.getVueController().saveMarkup(vueFrame.getActiveVueBean(), markupBean.getActiveMarkup());*
+// Close the dialog; if any error shows, the pop-up dialog emerges from elsewhere+
So in my case, the save markup action was invoked through the frame -> VueController -> Its methods. By using that method in the applet, ActionSave was called with the proper parameters. My guess is, for any existing action in the applet, the method will be similar. For custom actions, though, you will probably need to extend the frame or the controller on both ends, but have no idea about how to do that.
I hope this helps.
Edited by: Jordi Bosch on Apr 11, 2012 12:50 PM
I have done what you have suggested before but not really what I was after.
I wonder if we could use a URLConnection and post the write data to the request in order to get the VueServlet to behave how we want?
When the VueServlet is hit for a save or more specifically in my case I want to save markup entity data to another database so I want to be able to post my own data back to the DMS servlet.
Doing this from the applet has security implications which I want to avoid.
So take the following and say change <Save></Save> to <SaveEntityData></SaveEntityData> and this be mapped to a dms action called ActionSaveEntityData.
It seems a waste that the VueServlet can pass data to the DMS servlet to perform actions like save when it needs but not be used to invoke other custom actions when requested to save other 'stuff'
Thanks in advance for any help.
I had a similar issue. Save markup with its properties, or just save the properties? To separate custom actions or to use only the already existing ones?
In the end, my solution was to "use what I have been given": I generated a special property that discriminates the final back end action. So, in my system, "Save" will route all save actions, be it markups or properties, and an internal property acts as its selector. This way, both "save markup" and "save markup properties" in my system are passed from the applet as the same standard action, but on the ISDK back end I discriminate both through a custom property.
So this way, all database interaction ends being done in the back end of the ISDK, using Properties to pass data or conditions. Of course, you can add more custom properties if you need to pass connection details.
Edited by: Jordi Bosch on Apr 11, 2012 2:53 PM
I am not sure about this one. In my case, for the dialog I used as carriers elements already present on the original dialog, which were GUIElements in private DMSProperty buildMarkupDefaultGuiEdit(DMSBackendImp be).
To get back data from the back end to the applet, I guess you have to get again the bean:
bean = getActiveVueBean();
or its derived properties:
Property masterMarkup = bean.getMarkupProperty();
Property listMarkups = masterMarkup.getChildrenWithName(Property.PROP_MARKUP);
In my case, the second one appears to be enough to update the properties from the applet side.
Same strategy applies to the save markup
when there is a markup save query, the VueLink servlet gets invoked with the save command
that command has properties in them (describe the markup ie name, type, etc)
nothing prevents you from intercepting this call (or implementing the way you want) and
execute an extra step if you wish to do so
This markup save, will only be invoked for code relative to your integration
If you need to pass extra info (by that I mean values not files), you can use the Property associated to a markup
You could even customize your code to append extra data if that is not dome by the integration servlet (not recommended though)
Not all of the parameters on the property are shown, visibility of the various elements is controlled by the GUI section inside the CSI_Markups request
So you can have custom actions implemented as part of the markup save operations for markups files
that have an special property defined
when your file has an associated document property defined on the backend
The first approach will need to either hardcode a value or to query the backend for it when replying to the CSI_MArkup query
the latter will invoke the backend when the save operation is invoked. Not a big difference.
Do you have a code example you do not mind sending me to see how you did things?
I really would prefer a way to pass information back rather than get information.
Ricardo/Jordi: Do you think one of you could help me with another question on post - GUI files - using japplet.setGUI() security risk
All the questions I have ask are to do with a project we are working on mostly and the fast responses are very much appreciated, so thanks in advance.
Edited by: NickBannister on Apr 12, 2012 5:57 AM