I want to have a kind of view manager object to provide fragments created, chosen and changed at runtime for inclusion in a two-paned xml layout. Can I get this type of functionality by deriving from an adapter?
Related
We have a requirement of custom traits and the data for the custom trait should be fetched from our rest API.
Examples for traits we are looking into are like : Balance, Currency, Birthday etc.(Should be dynamic).
Business wants the ability to add a new custom trait from the configuration, with the data available from the rest api.
In case if we add new data items in the rest api we should be able to configure and use that custom trait corresponding to that data.
For this requirement,
I had gone through the Silver pop & Sugar CRM modules,
It seems like complexity involved to understand the login and external forms.
I have added some generic class implementation. But still I am not able to populate the traits in the Magnolia with data from rest.
I need few more clarifications regarding this.
1.How Magnolia recognizes the trait. Through Configuration/ something else(XML)?
2.If I try to generate the configuration with the static values in the version handler and called register methods by passing the tasks as parameters in the constructor. But still I am unable to see the trait configuration in the admin central.(config.modules.rest-traits-module.traits.balance.xml, config.modules.rest-traits-module.traits.currency.xml). Can we generate this kind of configuration as dynamic in Java code?
3.How can we set labels for the Traits instead of adding in Properties file? because we need them as dynamic.
4.Can we generate dynamic yaml files through java?(For traits configuration) If yes, does it support for Magnolia 5.3.9?
In the silver pop module they given some external form and its actions.. In my requirement i am not using any external forms? How can I proceed?
Does login is mandatory for this requirement?
Could you please suggest.
Thanks for your support,
--Vijay Kodali.
1.How Magnolia recognizes the trait.
You register the trait in the traits folder under your module. See documentation on creating custom traits for more info.
Can we generate this kind of configuration as dynamic in Java code?
Yes you can. Perhaps you made mistake somewhere in your version handler? Or it was not called because your module is already installed? Hard to say without seeing the code.
3.How can we set labels for the Traits instead of adding in Properties file? because we need them as dynamic.
not really "trait specific", but general Magnolia/Vaadin UI question. If you want to set labels dynamically, you would need to write your own FormPresenter (or View) implementation.
4.Can we generate dynamic yaml files through java?(For traits configuration) If yes, does it support for Magnolia 5.3.9?
Yes, you can generate yaml files through java. It doesn't matter what/whom puts them in filesystem as long as they are on observed file path.
And no, you can't register traits via yaml (yet) no matter which version of Magnolia you use. And in general yaml support is since 5.4 only, so it would not work on 5.3.9 anyway.
In my requirement i am not using any external forms? How can I proceed?
Traits have no direct connection to external forms. Those two are independent feature. In silverpop/marketing-cloud module they were used together since Magnolia was both producing data for Silverpop and consuming data from it, but you can have custom traits even without external forms. For more details see the above mentioned documentation on creation of custom traits.
Does login is mandatory for this requirement?
No login is not mandatory.
HTH,
Jan
I was wondering best practices for views of inherited classes in PureMVC in this situation:
Multiple classes inherit a BaseClass (lets say InheritedClass1 and InheritedClass2)
Each InheritedClass has a respective view (derived from a base view class, but each unique)
With a given dataset (lets say ArrayCollection of InheritedClass1/2 Objects), the respective views need to be dynamically loaded.
The dataset is relatively large, so a TileList would be nice (since it only instantiates objects which are currently displayed)
I can think of a couple solutions, but I find them to be too "hackish" to be the best solution:
In View: Repeater over a BaseClassView which attributes a view to a State (set to the "InheritedClass1" state to add a InheritedClass1 object)
Pros: No unneeded memory increase (States' objects are instantiated when needed)
Cons: View is dependent on the data types, so adds coupling
In Mediator: Loop over the ArrayCollection and addChild() the views based on data type
Pros: Works.
Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View. Slower than a Repeater.
Any comments or other suggestions would be appreciated. Thanks!
The answer is simple if you like the first example. Why not have a map (Object()) on the mediator that assigns datatype to view component (or states). e.g.:
private static var map:Object = {"ic_oneType": "ic_oneState",
"ic_twoType": "ic_twoState"}
And the mediator can assign that map to the BaseClassView.
I'm likely to agree with the idea that you need some form of viewProxy that renders all your inherited views based on data fed to it from the mediator (e.g., first example). Can confirm or deny whether states is the best course of action in your UI though without more concrete examples.
Mediators are part of the View. How would you separate them from the View is beyond me.
I'd got with option 2.
Here's a topic from the pureMVC forum: Dynamically adding View components: where should I do it?.
The post by "pureMVC" should be of interest to you.
Also, the size of the dataset can be problematic. If it's really large you should consider using a List with renderers instead of adding a component for each item (repeaters do that). Which would further complicate things a bit because you'll have to wrap your data to keep the main component decoupled of the Model.
Cons: View is dependent on the data
types, so adds coupling
Typically, a view component has no other purpose than to display the domain data and possibly allow the user to interact with it. It is a given that the view component will need to have some understanding of the domain data.
So feeding a collection of VOs to your view component doesn't add a 'bad' coupling. A 'bad' coupling is when the view component knows about how to reach into the Model tier and manipulate the Proxy that holds the data. Or when the Proxies in the Model tier know how to get their hands on the view components or their Mediators to poke data into them.
Mediator is adding things to the View,
which defeats the point of the
separation of Mediator and View.
As Coded Signal pointed out, we're not trying to separate the Mediator from the View component. The Mediator is the one actor in the PureMVC system that should know the view component, and mediate the communications between it and the rest of the system. The Mediator is the most critical actor in the system with regard to loosening the coupling between the View tier and the Model tier.
To communicate with the view component, other actors send notifications, which the Mediator hears and responds to by manipulating the view component's exposed API; spoonfeeding it data or invoking methods on it. This effectively keeps the rest of the app from needing to know anything about the component.
The Mediator also listens to the component for events and acts on its behalf, retrieving data from the Model tier, or sending notes to to other Mediators or to trigger Commands in the Controller tier. This keeps the component from having to know anything about the system it is connected to. It simply exposes an API of properties and methods, encapsulates its own behavior and sends events when things happen that the system should know about.
So together, the Mediators and View components make up the View Tier of the application.
-=Cliff>
Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View
Not really: they're what the documentation refers to as a collaboration pair and should be treated as such.
If so, are the results cached after the first access?
You may be confused as to what reflection really is. It's not a tool for parsing and creating objects, but rather analyzing meta data on CLR types. Here's the official overview of reflection.
Now, once ASP.Net creates instances of objects represented by markup (xml), it uses reflection to fill in property values on the newly created objects and does cache the metadata. It does all of this during the page initialization phase of the page lifecycle.
I have seen questions here asking about xsd->actionscript objects, but these seem to require xsd->java->actionscript and is all in source code. Our requirements are a bit different:
receive an xsd during runtime that we have never seen before
Create an instance object based on the xsd
fill in the values of the instance (either from an xml document or user input - whatever)
Anyone know of an actionscript library or tool that would help us accomplish this at runtime? It would be nice if something like this already existed - but we would certainly settle for a library that gave us a programmatic interface to extract information from an xsd schema. Additionally, we would take suggestions on alternate methods to accomplish the same ends.
Have you looked at the SchemaLaoder...? Not EXACTLY what you're looking for ... But a great start.
First - you should check this blog entry and this blog entry which walks you through Dominic De Lorenzo experiences with utilising functionality within the Flex SDK that provides the automatic mapping of custom ActionScript classes to element definitions within an XML Schema (XSD).
The steps to get moving here include (from Dominic's blog):
0) Create an instance of SchemaLoader and asynchronously load an XML schema from a given URL
1) Once the schema is loaded, add it to the SchemaManager and register any ActionScript classes to their corresponding schema type
---- At this stage you can do several operation based on the schema
2) Load an XML file based off that schema
3) Once the XML is loaded, decode the contents using XMLDecoder. Any classes registered in the schemaTypeRegistry will be used when decoding the xml
4) Encode a custom ActionScript class back into XML using XMLEncoder. XMLEncoder.encode() supports various ways to define the corresponding element in the schema (top level element, a specific type or even a custom XSD definition) that will be used to encode the Actionscript object.
The blog entry has links to code samples, etc...
Hope this helps.
I have a Flex app that needs some custom serialization. I tried to use IExternalizeable. If it worked that would be exactly what I need. But the issue is that I need to do this custom serialization on the client only.
It seems that to get the IExternalizeableized classes read/write methods called the Java classes also have to implement the interface. But the server already has all of the customization that it can handle; that is unfortunately not an option.
I tried to dig into the RPC classes. I was gonna monkey-patch what I needed. But I could only see the classes to handle the (AMF)XML data whereas I have the binary bits flowing. It appears that all of the serial/deserialization logic is already compiled into the player. At least that's my guess.
What I am attempting is to take the data from the AMF stream and update objects that already exist. Currently I am copying the values from the returned objects in my service handlers into the already existing model objects. I would prefer to skip the step where the NEW items have their values set and instead only set the values on the existing objects.