I would like to get some advice on architectural pattern to avoid module dependencies on Feature layer.
Every site has some sort content page like article or news. Those can be managed as Feature/article module Or Feature/news module. Both has common fields like title, summary and image.
Now I have created a Feature/FeaturedContent module. In which I have a slider with its own templates. But the content author want to choose and pick items from Article or News section
where only the title, summary and image will be used.
Hook up the items from different module is easy but when I render it with #Html.Sitecore().Field(Templates…. I will not have those fields(title, summary and image as the ID of those fields are different in each module) on my Feature/FeatureContent template. And I can't not make reference to other module under Feature layer. And I can't not add those fields as those fields are not belong to FeatureContent module. This is because Helix are not allowed to have dependence between modules under Feature layer.
I would like to get some advice on how to work around this.
I would certainly like allow the content author to reuse content from different feature module. I would think I have to move the common fields into foundation.
Any advices are highly appreciated. Thanks
Firstly, it's discouraged, but not impossible to have some inter-dependence in the Feature layer. Obviously this affects module coupling, so should be avoided where-ever possible.
In your particular case I think the approach should be to create a common base Feature with an "interface marker template" containing the 3 common fields you require, and the supporting Glass base classes (or other such ORM code). This module would then become a dependency to both the Article and News features.
While this is technically still a coupling issue, it still fits well into our SOLID principles, and it's still top-down in a sense. It might be tempting to mark this as a Foundation module but it really isn't so I would discourage that thought (in case you were going to have it). Think of this as an internal sub-layer in the larger Feature layer
Related
I am trying to understand the best practices for structuring an ember.js application. This slide from tomdale:
https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55
has a concise description of how to apportion the application logic. However in trying to follow these guidelines I have finding some problems:
The router is growing too large. According to the presentation the router "responds to events from views", but this results in a lot of code when there are dozens of views.
There are a huge number of controllers. In a Rails application the CRUD actions typically reside in the same controller, however for ember apps it seems that there should be a one controller to list records, one to view a record, one to create a record, etc.
It doesn't feel very DRY because I am ending up with so many files between the controllers, views and handlebars templates that each only have a couple of lines of code.
I am trying to decide if the problem is that I am applying the guidelines incorrectly, or whether these guidelines only work for trivial applications.
Does anyone have any advice - especially on how to manage the growth of the router?
I think that saying Ember encourages too many controllers is like saying Javascript encourages too many functions. Yeah, you can go crazy with proliferation of either. Or you can do the opposite, and have it work exactly as you need. In general, always remember that your app should be exactly as complex as it needs to be, and no more so. You don't need to use a certain architecture or pattern just because some famous coder guy used it, nor even because it seems to be 'the Ember way'. Even 'Universal Good Things' like Separation of Concerns, MVC, etc. are principles & models which you should try to understand fully then use to the extent that they serve your needs. I think that the ability to selectively break rules and patterns for the right reasons is far more telling a sign of a great hacker than slavish devotion to the dogma of the programming gods. This is a craft, not a religion. (But YMMV. Perhaps there's a special circle of hell reserved for coders like me. I'm betting against it.)
Specific to Ember, I tend to use Controllers around my data models and/or around a particular user workflow, rather than around each view. Then use Routing/State Managers as the glue between your views, and I generally use Event Managers on views to handle browser events within each view, including sending instructions to the router. So, if I have an app that revolves around, say, Customers and Products, I'll have a controller for each, just as I tend to do in Rails. This will result in each controller holding more functions and computed properties than some people like to have in one place. It also means that I can't necessarily reuse my views in another context, because they're hard-wired to the controller. And yes, this is poor Separation of Concerns. But that's not an absolute good if it causes complexity that has no payoff.
Also on the subject of Controllers, I think folks particularly tend to proliferate controllers unnecessarily for subsets of your main data model. Say you've got a products controller, and you want to store the products that a given user is collecting in a comparison tool. Most people seem to create a new controller for this, but it's perfectly legit to push these into an additional array or other Enumerable inside of your Products controller or Customers controller, or on your Customer model. This keeps objects that rely on the same functions and properties within a closer scope. The content object in each controller is, AFAIK, just another Enumerable. It has a few special implicit references to the Controller, but isn't magic. There's no functional reason I've found not to use additional ones too. They work just as well with bindings, with #each, etc.
Similarly, some people just LOOOVE to break their app down into a million files, nest them 15 deep in the file structure, etc. More power to you, if that helps you to visualize the underlying logic, and make it clear to the rest of your team. For me, it just slows me down on projects with only a 1-3 person engineering team. Folks also tend to reproduce the file-based style of other MVC systems they're familiar with (like Rails), where files are the necessary explicit structure for separating views and other logic objects. This becomes an article of faith and a deeply ingrained habit. But in Javascript MVC, I have found that it often serves no such purpose and is strictly redundant to the implicit design. I tend to use a single, carefully organized file for my entire Ember app (separating it from any other non-library JS), with lots of indentation and nesting where that helps me to visualize the hierarchy. Whatever you do, file-wise, it's all the same at runtime, provided that you deliver it all to the right place at the right time. With Ember and JS, file structure is for the needs of your team, and nothing else. Calibrate accordingly.
(IMPORTANT CAVEAT: if you do use a million files, you'd better be using a pre-compiler to manifest them all together for delivery to the user, or you're going to take a huge latency hit on delivering all those files separately.)
(ANOTHER IMPORTANT CAVEAT: with a large team or a rapid daily release schedule like GitHub's, file-based separation of your logic can make version-control easier than doing lots of merges into the same file, where your merge tool may get confused. Again, this is an issue of managing and monitoring your human processes, and doing merges carefully, rather than a technical requirement imposed by your JS framework.)
(LAST IMPORTANT CAVEAT: Then again, sometimes the difference between a technical requirement and a human/procedural requirement is fuzzy. If you break your developer's brain, you also tend to have a broken app. So, do what works for the people and processes you have to deal with in getting it built.)
As I said before, YMMV. I'm not a coder God, as you can tell from my reputation score, so you may feel free to disregard me. But I stand behind the idea that you should use only as much complexity, only as much file-structure, and only as many higher-level abstractions (like routing, which may actually be overkill for limited-purpose single-page apps) as serves your needs; and no more.
I think we are developing a quite large ember app (about 45 views at the moment). It implies almost the same count of controllers and templates).
Indeed our router is quite large, but we manage it quite easily by splitting it into many files. Basically, each file represent one screen of the app and is responsible for maintaining a functional set. Here is an extract of the router:
Router = Ember.Router.extend({
root: Ember.Route.extend({
index: Ember.Route.extend({
route: '/',
unlogged: Ember.Route.extend({
route: 'welcome',
connectOutlets: function (router) {
var applicationController = router.get('applicationController');
applicationController.connectOutlet('welcome');
}
}),
logged: Ember.Route.extend({
route: 'app',
projects: Ember.Route.extend({
route: 'projects',
collection: ProjectsRoute,
member: ProjectRoute,
showProjects: function (router) {
router.transitionTo('projects.collection');
}
})
})
})
Then it the same in the ProjectRoute. Each time there seems to have to many feature in one route, we split it.
You can even reopen a route to extend it, and to plug other functionnality in it.
ProjectState.reopen({
scenarios: ScenariosRoute,
showScenarios: function (router) {
router.transitionTo('scenarios.collection');
}
});
It implies more files, but with a good organization, it's no hard to maintain, as it's very rare you work on all features at the same time. Usually, I have nore more 4 opened files simultaneously (view, controller, template, route)
I don't know if it's a best practice, but it works pretty fine for us
I have been learning PHP MVC pattern and it is pretty cool. have almost finished app and I can see how mess you can make a code without good design.
Now can MCV be applied to C++ apps? Where does Plugin manager/Plugins go if that is even possible?In model or controller?
Thanks!
EDIT:
I mean C++ with GUI toolkit like QT/Wxwidgets/GTK+
Also Please help me on how to implement in C++. I have learned how to do it in PHP but as you know the two languages are somehow different!
EDIT2
http://forums.wxwidgets.org/viewtopic.php?f=1&t=30983
how do you actually implement it in C++
make classes in charge of rendering know nothing about application details. Call them SomethingView classes to make this point clear
make your domain objects not know anything about visualization or user interaction. You don't need to call them Model, but you could
create a set of classes in charge of running the role of Controllers: wire somehow dependencies to view and model classes via dependency injection if possible. example: CppInject. In any case, controller classes can know both about model and view classes, so the important part is this: all the coupling between view and model objects is isolated to the controllers.
Also, this implies, that all imperative-style programming should be confined to the controller classes as well: view and model should be declarative-style. That means, they should offer services related to its role, but avoid direct interaction with other objects as side-effects
It is not true you need to implement communication between controllers and the other components with event-style system, although such system is definitely helpful, but certainly not required
surprise! the above applies to any language or framework, except of course languages that somehow already force MVC down your throat from the start, i.e: ruby on rails
MVC is a design pattern not a language specific construct, So yes you can apply it to C++ app as well.
MVC can and should be applied in any language so your User Interface is loosely coupled with the backend & either can be changed with minimum impact on each other.
The MVC pattern provides a clean separation of objects into:
Models for maintaining data,
Views for displaying all or a portion of the data, and
Controllers for handling events that affect the model or view(s).
Yes, MVC can be applied in C++. For example, the MFC framework uses Document/View architecture which is essentially an MVC.
A design pattern isn't a library or class. It's a pattern. So you don't have a generic MVC library for C++.
Use Tree frogs Framework. TreeFrog Framework is a high-speed and full-stack C++ framework for developing Web applications.
MVC is an architectural design pattern (i.e. a way of building software) commonly associated with web applications, but it is applicable in general to any software project in any language. You have to make a little abstraction effort on your project, and identify which piece of software belongs to each part (i.e. a GUI is probably part of View, etc.).
Note that this type of pattern is mainly aimed to separate developement, so that any part of the project can be developed regardless of the others. This can be annoying for a small standalone application, but useful and rewarding on bigger projects.
Personally, I use boost state machines for the logical and boost signals to connect things together.
I wrote a little example that you can analyze here:
https://github.com/edubois/mvp-player
What are some common use cases for implementing CFML Custom Tag (not CFX tag)? In 3 yrs of my CF exp I've never written one. Would someone please enlighten me, under which use case / situation would one choose custom tag over cfc / udf?
Remember that custom tags were, at one time, the only method available to extend CFML (up until version 4) - UDFs came later (CF 5) and CFCs later still (CF MX). They're not as commonly used as they once were for the simple reason that there are more options.
Custom tags are basically procedural in nature in a language that, with CFCs, become more and more OO in practice. This is another reason that they're not very common.
But there's still cases where they come in handy (but are never required) - mostly for interface work. The ability to create both a start and end state can definately come in handy. A simple example could be a "wrapper" for page content the opening tag might add the HTML header and page navigation while the closing tag would add the footer and end the page.
In this way your page content could be nothing more than:
<cfmodule... >
Page Content!
</cfmodule>
Of course there are other ways to do this as well - but sometimes the classics still have value. ;^)
Look at the CFUniform project for a great example of custom tag usage. Custom Tags are great when building reusable pieces for the UI portion of an application.
I think that, for the most part, custom tags have mostly fallen by the wayside since UDFs, CFCs, and integration with Java (and to a lesser degree .NET) allowed easier and more straightforward ways to do similar things.
Looking back to when I started in CF5, I can think of several examples. A good one might be CFX)Zip, which allowed interaction with Zip files before that was available directly through CF.
The only use I can think of offhand in a more modern context would be to provide precompiled code that wasn't written in Java or .NET, such as proprietary doodads written in C. That's a pretty niche use, though.
Honestly, I imagine at this point they exist more or backwards comatibility than anything else.
Ever since CFCs came out I've stopped using custom tags simply because of the overhead. They take too long to initiate and execute. But like #Jim Davis said, they may be useful where you need to write a tag that wraps around other content.
But in a well defined solution, you can do way with them all together.
I tried to design the ui with some ui mocking software, but i found it's hard for me to settle down all the detail of the design, since the database didn't design yet.
But if i first design software, then the same problem occur, I didn't have the UI, how can I create a prominent UI ?
UI first.
Mock up an elegant and easy-to-use user interface (and workflow) thinking from the point of view of the user, and only then think about the underlying database / data structures you'll need to bring that UI to life.
If you can't design your UI because you haven't yet designed your database, you're doing it wrong IMHO. How many annoying pieces of software have you used that suffered from letting the database design drive the UI design?
Edit: As others have pointed out, you need to start with use cases / user stories. The UI design and database design, whichever order you do them, should only happen after you know what your software is trying to do, and for whom.
Edit by Bryan Oakley:
(source: gapingvoid.com)
Put the user at the place he deserves. Design UI first.
Database is only a consequence of user needs.
use cases first, neither ui nor database.
If you're trying to solve a problem in an object-oriented language, it's recommended that you start thinking about the objects involved. Don't worry about the database or the UI until you've got a solid domain model nailed down that addresses all the use cases.
You don't worry about the database or the UI at first. You can serialize objects to the file system if you need persistence and don't have a database. Being able to drive your app with a command line UI is a good exercise for guaranteeing that you have a good MVC separation.
Start with the objects.
UPDATE:
The one advantage that this approach has is that it doesn't prejudice the UI with a particular database design or vice versa. The object are agnostic about the other two layers. You aren't required to have a UI or relational database at all. You're just getting the objects right. Once you have that, you can create any UI or persistence scheme you like, confident that the domain model can handle the problem you've been asked to solve.
All the above answers address your issue in a right direction. That said, I would follow the SDLC thoroughly. It helps you understand the need for the solution for the problem at hand. Then comes the requirement gathering followed by the design either UI / underlying structure that supports the UI. It's a procedure but you would benefit in the end.
Your question is very subjective.
My opinion (and it is just that) is that database and underlying structure should come first. It can often help to put down the keyboard and mouse and compile some notes on paper.
Lay out goals like what you want your application to do, list the features you require and then start thinking about how you'll build it.
This method works for me in application design.
usually you need to manipulate some data in the solutions you develop. So you should consider how this data is organised first, stabilizing this layer is fundamental at the beginning. I agree with duffymo's comment about designing the business objects first if you are in a OO world. Mapping these objects to the DB will be a part of your work. Then you add business functionality and work on the presentation layer. Of course you will have to do some refactoring from time to time, but usually the refactoring impacts the business and presentation layers more than the database.
read this, it is a good technique.
DDD - Domain Driver Design
Would you build a house without a foundation? Database design isn't the fun part but it is the foundation of most business apps and if you get it wrong it becomes the most costly to fix and the most costly to maintain.
That said, I note that there is no reason you can't work on both together as they intertwine. But before you can do either, you need to understand the requirements and the business you are writing the app for.
For quite a long time now, I've been trying to write and have been in search of "a really good" CRUD application. Don't get me wrong - I didn't say "The ultimate" CRUD application. Just one that could be rated 1st class.
What I'm saying is: Please don't respond to this plea with an answer like "Well, every situation is different..."
Q: Is there a blog post or something in the Adobe documentation that shows CRUD on a one-to-many relationship (Header/Detail), that uses web standards css (instead of tables), that uses best practices (CF9 has changed so many things now: scripted components, ORM), that uses the latest UI techniques (jQuery or some of the built-in AJAX features of CF9), that has a nice front-end (a nice looking header and background along with some pretty buttons)?
I know that's a lot to ask, but such is my quest.
A good example of a one-to-many relationship is the city/state xml files built into the Spry examples. There are 23,000 cities in the sample xml files, so I think that's better than just using random data.
I'm not really sure what you're asking, but I just want to respond to a couple of points in your question (this is more a comment than an answer, but since SO is stupidly limited in this, I'll put it here instead.)
that uses web standards css (instead of tables),
There is no "css instead of tables" - they are two distinct and compatible things!
CSS describes visual aspects of a document, whilst tables markup tabular data.
If you're displaying tabular data, then tables is exactly what you should be using, and you can use CSS to make it look more exciting than the plain styles that tables come in.
Since you're asking for a CRUD app, odds are you are going to be wanting to display tabular data so should be using tables.
(The common mistake people make is not understanding the nature of the web, and using tables to apply grid layouts to documents, when they should be using strucuted semantic markup instead.)
that uses best practices (CF9 has changed so many things now:
scripted components, ORM)
Scripted components are not a best practise!
They are an alternative syntax (for people that prefer having non-descriptive braces everywhere) they do not offer anything you can't already do.
i would strongly suggest you check out cfwheels. read the documentation, it's built for doing such crud applications and has an amazing set of features and will save you a lot of time. as for the interface, there are many jquery plugins out there that can handle this. i suggest looking at ajaxrain and find a plugin you like