I have a UI application which contains a dialog allowing to edit/create an entity. However create/edit classes share much code. What's the best names you can suggest for the base class?
Related
I'm new to CQ5 and working on a project that deals with refactoring code that uses design dialogs.
Currently, I have a property declared as part of design dialog of my component. It creates a folder in /etc/designs/ for each template my component is used on. Is there a way we can make sure that those property values are stored at one particular configuration in /etc/design(as opposed to multiple)? I need to make sure only one set of configurations is used for all pages that use my component.
Thanks in advance!
Pallavi
The designs are linked to the template and not the whole site.
Hence whenever you configure the component in design mode, the values are stored within the corresponding template under the jcr:content of the configured design page or under /etc/designs/default/jcr:content in case no design is configured.
As far as I know, there is no way to tell AEM to store all the design configurations under one single path, unless you are using absolute paths in your dialog / page configurations.
If you are using multiple templates in your site, there must be one master template (which render global components eg. header/logo/navigation & footer), and all other templates should extend master template to get these global components and change pagelayout for content section.
Saying so, if templates are structured & inherited properly, you should be able to set design dialog property on home page (created using master template) and all internal pages will be able to access those design property OOB. Though child pages (created using other template) can override those design property (if needed for that template) to break inheritance.
I have a windows form with a label on it. I want to set the labels value at runtime depending on which assembly is inside a directory. I am not sure which code goes where:
UI Form has a label.
2 class libraries that implement an interface.
Should I have another class that does the MEF composition work and do I need to call that in the constructor of the UI Form.
If I need to call it at the forms constructor and I have many forms, does this mean I have to call it in very form.
I am using MEF for the first time in a WPF application I'm developing and what you describe above is about how I managed my MEF modules.
Below is a summary of what I have done:
Create a separate class for MEF composition. I named mine Modules. This class should do all of the MEF composition. You can either do the composition when the object is created or make a method for it. (Modules.DoComposition())
I create an instance of this Modules class in the constructor of my main UI window. Composition will be done at this time. (Create in the ViewModel if you are using MVVM design pattern.)
I pass a reference to my Modules object in the constructor of any additional form that needs access to it. That way all forms will have access to your Modules object without needing to do composition again.
Is it possible to add attributes to a Visio (in my case 2007) UML diagram Interface object? It shows operations in its properties dialog, but alas no Attributes section. I am really hoping someone has thought of a way around this (without looking at third-party apps).
It is possible to achieve the same visual Effect: An interface is represented like a class with a stereotype <<interface>>. So you can go to UML/Stereotypes/New and enter "interface" as Stereotype name, then select Class as base. Now you can Create a new Class, edit it and select the new interface stereotype. After doing so you have a visual representation of an interface which can hold attributes.
Maybe this suites your needs. Still the internal representation of these models is not UML 2 compliant (but Visio has other flaws regarding that either way).
What's the best way to extend the users area? I want to add a field to the User Types where you must select an Administrator (by User Type) for each particular type. I don't see any way to extend this area, does it have to be done in the source code?
There is no way to extend a User to add more properties that I"m aware of. You could create a new table in the Umbraco database and then use an XLST Extension or C# class to get the extended properties in a Razor macro or User Control. However, you would have to create a custom folder in the Users section (or a custom section) to allow editing of the extended properties in Umbraco.
I'm building a Zend-based Web app that will permit third-party extensions.
Essentially, this application's database will have a generic "content store." Extensions are added to render different pieces of content in different ways.
Think of a rich mail store: When the user asks for a "Calendar" item, I instantiate a Calendar class (or something) and ask it to render the item's content. The same database might contain "Mail" items, which are rendered by a different class (or whatever). So I'm basically defining a base class with the needed methods to handle content items, and then add-ins are written which inherit from that to deal with specific item types.
Each of these add-ins may need to access its own View files, since each of them will obviously have a different visual layout.
I can't foresee all the content renderers that might be used; new ones will be "installed" (in some fashion) so that my application knows "when I see content with a database type column of XYZ, I'll call the XYZ thing to render that."
Likely, what will happen is this: User will visit a URL for the application, thus triggering an action within a Controller. That Controller will use a Model method, telling it which specific content item was requested.
From there, either the Model or the Controller (which?) needs to call something (what?) that gets the item from the database (okay, the Model clearly does that) and renders it using some predetermined View. This would be PART of a larger page that might well include several rendered items (as in, a list of content items).
So two questions:
What's the best way to architect this in Zend Framework? I do want these add-ins to inherit from a base renderer class that I provide, because very simple renderers may simply need to call functionality from that base class, rather than having any of their own code (e.g., a "Note" and a "Memo" might well use the simplified rendering functionality from the base renderer class).
What's the best way to "register" these add-ins with my application? An .ini file, perhaps a database table? The goal is simplified installation steps for whoever is operating the application - e.g., editing an .ini file is often easier than manually querying a database, although I could also provide an admin back-end UI for new content renderers to be registered in.
I'd implement the Visitor Pattern for this.
Each third-party extension should implement an interface that you define, so that you know you can call a specific method, say render() on any object that is an instanceof that interface.
Each extension then implements its own rendering. Perhaps it utilizes a View partial in the Zend Framework architecture. Or else perhaps it uses some totally different code to render itself as a PDF or something (maybe each extension needs to be able to override content-type headers?).
As for how to register it, check out the Zend_Application framework for defining resource plugins.