I'm using the Magnolia Spring Integration (Blossom) for my web app and I definitely don't understand how (if it's even possible) to share a unique area between two pages.
This is how I've worked so far :
I have three templates main-template, template-1 and template-2.
template-1 and template-2 both redirect to main-template by redefining their own "body" areas.
In the class of template-1 I have three areas : content-area, area-1 and area-2
In the script of template-1 I include the three areas with the following directives : [#cms.area name="content-area"/], [#cms.area name="area-1"/] and [#cms.area name="area-2"/]
The same areas are defined in the template-2 class and script
What I want is to share, lets say, area-1 between template-1 and template-2. The problem is that by redefining them in each class they are considered like different areas...
Through my tests and the magnolia documentation, what I understand is that an area can only be defined within a template class so it can be accessed in the script of this template and only the areas defined directly in the template class associated with the page will be process/rendered.
No matter what I try, as long as the areas are not defined in the page's template class they cannot be accessed and therefore included pages don't have their areas rendered.
Does anyone have a clue in how I can "include" or process "areas" from other templates in another one ? Or am I doing it all wrong ?
Thank you for your time.
regards.
I know this is an old question, but it is still a valid question, so let me answer it:
As far as I know areas can inherit from other areas (normal Java class inheritance using "extends ..."). As far as I know this wasn't available in 2013 yet, but it is now. I know this because I filed this as a feature request once and it was marked as solved at some point, and I think I also successfully used it once (don't remember clearly).
If for some reason it's still not possible to extend areas from super classes, then you could still use conventional tools like putting the logic to a helper class and making the actual areas very slim (that is just calls into the shared helper class). And the actual template (.jsp or .ftl file) can be shared anyway.
Related
Here is an interesting problem regarding the IncludeEventHandler.
I am developing a Spring-Based application which uses velocity which has different VENDORS having a separate portfolio site. I am letting vendors customize the pages by providing them the Velocity templates which are being stored the database and are picked up by the velocity engine using a DataSourceResourceLoader.
My table is organized like this.
The vendors may parse other templates by calling the macro #parse and passing their vendorid/template-name so that it looks like this.
#parse("20160109144/common-css.vm")
Now the actual problem is picking up the template according to vendorid.
I have a class (extending IncludeEventHandler) which overrides the includeEvent method. Now what can I do to return the desired template? I dont want to change the names and make them look like 20160109144/home.vm
With OP's question, the intent was to provide an alternate behavior to the DataSourceResourceLoader.
Unfortunately, the Velocity Engine version 1.7 doesn't have ability to change the SQL statement that is used to retrieve the template.
The DataSourceResourceLoader extends the ResourceLoader abstract class. That said, if you reference the source, you should be able to implement a custom ResourceLoader that behaves the way you want it to.
One option, glom most of the code from DataSourceResourceLoader and change the way it determines the template content to load from the database.
I would dump all of the query related material as you will be determining the specific columns you want to load for content. The DataSourceResourceLoader essentially maps the name of a template to a database entry and your implementation essentially revolves around the rules you've defined above.
Hopefully that can provide enough assistance to move forward. I would recommend pulling this in a debugger as well and determine what is and is-not passed in to the related load methods.
I'm making a leave management (HRM) website. I'm using codeignitor HMVC to build this. Following features are included in this site:
A table to display a summary of leaves.
A table for leave types like annual, MC, urgent, other...
I was thinking to create two modules for leave_summary and leave_types, but my friend told me it is useless.
According to HMVC architecture we are trying to create self contained modules for reusability. If I'm creating a different module for leave types, I should be able to reuse it and module itself needs to be self containing. But I can't use leave_types module anywhere else.
My friend asked me to put all the leave related stuff in one module called leave. This sounds strange to me as I found lots of examples people are trying to separate things out.
Do we only need to separate the modules which can be reused in the future (ex: login module, image_gallery module, profile module) and keep all others things inside a one module?
(according to the above example I have to keep everything related to leave in a one module
ex: leave_type, leave_requests, leave_summary will be placed inside the leave module)
What are the benefits I will get, if I separate the leave_type, leave_requests, leave_summary etc... into separate modules?
Will I be able to reuse them? If so How?
In HMVC model classes and other assets can be exchanged among the modules, so how can I call it a self-contained module or a separate entity as it is depending on another module?
(ex: I have to call leave_type module's model class inside the leave_summary module to show the leave type name in a table.)
I'm little lost here. Please help me to understand. Thanks a lot!
As i work lot of MVC projects. And I am agree with your friend.
May times this question arise when i used join that i have to choose in which one module i should go for write query. If you write in one model may next developer will write in another one model.
So according me it is best to keep same type of tables which are handling relation and using for same behavior use this approach like leave model, profile model etc.
I'm quite new to Prism. I'm studying QuickStarts shipped with it as well as other examples on the net. Almost all of them make modules aware of what region their view(s) get dropped into. Typically, the method Initalize of a module has a line like the the following.
RegionManager.Regions["LeftRegion"].Add(fundView);
I feel quite uncomfortable with that. There's a similar discussion but I think that it should be the responsibility of the shell component to define such mapping. However, I cannot find any example of such approach and I'm not sure whether the bootstrapper is the right place to put such mapping in.
Is this approach completely wrong?
Nothing is completely wrong. But it makes no sense to have the shell/bootstrapper (that by design doesn't know anything about the application it will host) knows what view goes into which region.
Consider an application that can be extended by simply adding modules into a given folder. When you follow the approach that the module knows where it's views want to reside (the mapping is done in Initialize()), this is no problem. I designed my first Prism application that way.
But if your mapping is done in your shell you always have to update your shell (which is part of the base application, not any module) when you want to add another module. This runs contrary to the loosely coupling paradigm. Besides that you have to create one base application for every module constellation. And there are (2^number of modules) permutations you have to cover. That results in loosing your flexibility you gained by using Prism.
I'm working on a joomla component that includes building a schedule. On any given day it needs to look at a set of rules (day of the week, date of the year, type of event) and return all of the possible start times. It would make sense to have a class that calculates these things, but I'm not sure it fits in the model or controller (and certainly not view) categories. Am I supposed to create a com_myproject/lib (or similar name) and have joomla auto-load the classes?
I'm new to joomla and started with the framework/project provided at http://docs.joomla.org/Building_Joomla_Extensions_with_Apache_Ant.
You should create a helper class. Have a look here for an example, albeit it is for a module, but the same concept applies.
You might want to start off with Developing a Model-View-Controller Component - Part 1 tutorial and work your way through that by hand. Using Apache Ant to learn how write an extension is like taking a canon to shoot fish in the barrel. It can be done but probably not the best way of doing it.
The Joomla! MVC pattern is very peculiar and difficult to understand. I don't quite understand it myself. I was advised on the developer email list to look at how other components are put together. Guess what? All the other developers do it differently, with some of the bigger components looking like spaghetti code in their organization.
The bulk of your component code should be in the controller, either as part of the controller class or a separate class file that's imported in. You don't need a separate library directory unless you're working on a big component with multiple class files. This Joomla! thread might be applicable.
So thanks to the Visualization and Modeling Feature Pack , I can build a uml model diagram and generate a bunch of classes.
But what now? Presumably, my developers will add code to those classes. Useful code, valuable code, and as the templates themselves indicate:
// Changes to this file will be lost if the code is regenerated.
So what is the best solution here? Can I make the modeling project reflect changes to the actual classes? Should I generate partial classes? Modify the default templates to read class files and not auto-generate anything that has been modified? Should I tell developers not to edit model files under pain of....well, pain?
Thanks for the tips.
As far as I know, this is really the key reason for partial classes in the first place. The custom code goes in one file, the auto-generated in another.
You could also create classes derived from the generated ones, and put any changes in there. I also agree with above poster that partial classes could be the way to go.
Although the tools generate basic skeleton classes out of the box, that's really just a starting point. You can easily adapt the generator templates to create your own stuff. Different people want to generate different code from the classes - some even generate XML or SQL. And yep, in C#, partial classes are good to generate, so's to keep the hand-written code separate from the generated bits.
It's good to put lots of extension points in the generated code, where you fill in the details by hand code.
Another neat idea is "double derived": from each UML class, generate a base class and a derived class. The derived one has only constructors. The base class has any methods you generate. So your hand code can easily override generated methods where you need that.
There are several options in the tool and recommending what is best is hard without knowing your scenario. Partial classes are great for some, but not all applications. If you want your UML class to generate a partial class, you can set it's C# stereotype's property to "Partial" and it will do so, and custom code can then be added in a partial class that won't be overwritten. If you want to prevent code from being overwritten, you can do this by setting the overwrite property to False on the template binding that corresponds to the package you are working on. This lets you set your extension code to be in a package that is not overwritten, while your model mastered code is overwritten with the latest model changes. Finally, if you want your code to be the master for your model so it always reflects the latest code, then you can reverse engineer your code by using the architecture explorer to select your classes and then dragging them in to a UML diagram. So for a given gesture, either the model is the master or the code is the master. In this version, we did not implement automated merge capabilities between the two.