nnsoft - Frameworks

Concerns

nospam@example.com (chnghia) — Fri, 20 Jan 2006 10:33:40 +0100

How does open source fit into the enterprise architecture?

What is the best path for migration of proprietary legacy applications to open source?

What open-source alternatives exist for different proprietary products- and do they meet the enterprise needs?

What are the technical capabilities, features, and functions of various open-source applications?

What kind of support services exists for the open-source applications?

Midgard CMS Features

nospam@example.com (chnghia) — Tue, 17 Jan 2006 10:13:42 +0100

Midgard CMS is a comprehensive Content Management System. The features in Midgard CMS include the following:

Comprehensive authoring tools

Website management

Multilingual support

User management and access control

Web developement

(midgard-project.org)

Content Management and Information Architecture

nospam@example.com (chnghia) — Fri, 13 Jan 2006 12:57:54 +0100

Lou Rosenfeld is an independent information architecture consultant. He has been instrumental in helping establish the field of information architecture, serving as president of Argus Associates consulting firm from 1994-2001. With Peter Morville, Lou co-authored the best-selling book, Information Architecture for the World Wide Web (O'Reilly), often known as the "Polar Bear" book.

CMSWATCH: How do you define Content Management?

CMSWATCH: So, where does IA end and CM begin?

by Tony Byrne (cmswatch.com)

Comparing Portals, CMS, and "Nukes"

nospam@example.com (chnghia) — Fri, 13 Jan 2006 11:21:46 +0100

You can find a variety of definitions of content management systems and portals, and most of them will overlap; hence so much confusion in the marketplace.

A portal generally delivers content so it can be consumed. But portal software packages typically aggregate content and data from a variety of locations, and in many cases, include search and collaboration services as well. A web content management system generally supports the production of content, but some CMS products deliver content as well, which can make them "portal-like". This is especially the case in the open-source world, where CMS packages often grew out of dynamic page delivery systems.

The "Nuke" variant of open-source portals is a classic example of a hybrid approach. Designed originally for community-oriented sites, nukes emerged to foster easy publishing of various different content types, but the key architectural consideration is that site visitors are often authors, and vice-versa. Nukes are also characterized by the plethora of other site-management and community tools that are typically woven into overall package. Think community website in a box.

This makes nukes ideal for certain types of sites, like fan clubs, or certain type of collaboration-oriented intranets where a wiki may be seen as to open-ended.

There are various flavors of nukes, some of them with long (and colorful) histories. DotNetNuke is simply a variant built on the Microsoft platform.

(cmswatch.com)

Difference between a Content Management Framework and a Content Management System?

nospam@example.com (chnghia) — Fri, 13 Jan 2006 10:54:52 +0100

The distinction between "framework" and "product" is most pronounced in open-source community (c.f. the OSCOM matrix). People throw the two terms around loosely, but a framework typically represents a technology platform of base architecture, on which a CMS is a product (or several) can be built. I think this a useful distinction, commerical CMS products roughly divide along these lines too, although most vendors now avoid calling their offerings platforms in an era where "out-of-the-box" has became de rigeur.

The good news is that separating technology between underlying platform and more concrete products represents good architecture. The bad news is that frameworks are sometimes an excuse for not doing the hard (but essential) work of applying business context and real usability to the technology.

You will be hapiest with a platform if you have substantial developer resources, unusual or highly complex requirements, and suitable patience. If you want something quick to implement, that provides the basics (usually), and you are willing to sacrifice some functionality or features (ah... but which ones?), then a product might be better.

by (cmswatch.com)

Tutorial AJAX with WACT

nospam@example.com (chnghia) — Tue, 20 Dec 2005 15:47:53 +0100

After checking out the lastest WACT build from CVS, integration of AJAX functionality became a whole lot easier. This is a simple example of using the Prototype and Script.aculo.us javascript libraries to implement a rich UI with WACT. First of all, the controller itself:

<?php
?>

Here's our HTML template (application.html)

<?DOCTYPE html

The script block bellow automatically performs the linking of the textbox (ac1), the AJAX request and the response container (ac1update). When the value of the textbox changes, the onChange() event will be triggered and the Prototype framework will compose a complete POST request to '/samples/controllers/application.php/search' will direct the request to the CommandController named 'search' that's been registered as the child of the root PathInfoDispatchController.
<script>

</script>

The results array will be populated in results.html

<list:list from="results">
</list:list>

The populated template will be sent back as the response to the POST request made by the autocompleter. Once the autocompleter receives the response from the server, it will insert the unordered list into the container specific (ac1update) as innerHTML.

And there you have it, Ajax goodness with WACT!

(www.phpwact.org)

You Aren't Going to Need It

nospam@example.com (chnghia) — Tue, 20 Dec 2005 13:30:14 +0100

You Aren't Going to Need It

"Always implement things when you actually need them, never when you just foresee that you need them."

Drawbacks of MVC

nospam@example.com (chnghia) — Tue, 20 Dec 2005 13:27:06 +0100

Increase complexity

Close coupling of views and controllers to model

Potential for excessive updates

Close coupling between view and controller

(www.phpwact.org)

Benefits of MVC

nospam@example.com (chnghia) — Tue, 20 Dec 2005 13:06:04 +0100

Substitutable user interface

User interface components

Multiple simultaneous views of the same model

Syncronized views

Easier user interface changes

Easier testing

(www.phpwact.org)

Platform Independence

nospam@example.com (chnghia) — Tue, 20 Dec 2005 12:16:04 +0100

Typically each concern of the MVC triad has ties to a specific platform. It is possible to isolate these platform dependencies from the platform independent portions of the application by splitting each concern using the Bridge pattern.

(www.phpwact.org)

Scale and Granularity

nospam@example.com (chnghia) — Tue, 20 Dec 2005 11:30:37 +0100

The MVC pattern is applicable at many different scales in an application. At the lowest level, an object implementation involves three objects two with Document View. Although three objects are involved, only a portion of each object may be involved in any given MVC triad at the smallest scale. For example, a checkbox view/controller component operates on a data value from a model object. MVC is the easiest to understand and implement at the lowest level of granularity.

These small triads can be combined and composed into larger triads. checkboxes and text fields into panels, panels into windows, windows into applications, etc. At each level, the separation mandated by MVC are maintained. At the higher levels, each concern might be considered a layer or package containing specific classes.

(www.phpwact.org)

Relationships between components

nospam@example.com (chnghia) — Fri, 16 Dec 2005 16:07:56 +0100

View-Controller Relationship

In traditional smalltalk MVC, views and controllers are tightly coupled. Each view instance is associated with a single unique controller instance and vise versa. The controller is considered a Strategy that the view uses for input. The view is also responsible for creating new views and controllers.

It is logical that views and controllers are strongly related, the input and output of an application is strongly related. In most GUI MVC frameworks, the view and controller are simply merged into one object. This is called Document View. The view and controller are combined as the view. The model becomes known as a document.

A passive model shifts more responsibility into the controller, as it must notify the views when they should update.

The modern web usage of MVC shifts even more of the traditional responsibilities of the view to the controller. The controller becomes responsible for creating and selecting views and the view tends to lose responsibility for its controller.

Sometimes responsibility for creating and selecting views is delegated to a specific object, this is known as the Application Controller pattern for web MVC and View Handler for GUI MVC.

The rigid request/response cycle of HTTP may make the Document View variant less popular in web applications although the controller is still strongly related to the view. The HTTP request is handled by the controller, the processing to the model, and the response is handled by the view.

Model-View Relationship

Model-Controller Relationship

(www.phpwact.org)

Controller

nospam@example.com (chnghia) — Wed, 14 Dec 2005 14:34:15 +0100

The controller receives and translate input to requests on the model or view.

The controllers are typically responsible for calling methods on the model that change the state of the model. In an active model, this state change is then reflected in the view via the change propagation mechanism. In the passive model, the controller is responsible for telling the view to update.

In MVC, the controller is NOT a Mediator between the view and the model. The controller does not sit in between the model and the view. Both the controller and the view have equal opportunity to access the model. The controller does not copy data values from the model to the view, although it may place values in the model and tell the view that the model has changed. see Presentation Abstration Control where the control layer acts as a mediator between Presentation and Abstraction.

The word controller is overloaded with different meanings in various patterns. see what is a Controller Anyway. There are several of these controller patterns: Front Controller A single point of dispatch for incoming http requests. Page Controller Controls the flow of logic of a single web page. Application Controller Controls the flow of logic of a single application.

Because the popular MVC framework Struts implements a combined Front Controller and Application Controller, some people assume that this is what is meant by the MVC pattern in the context of a web application. For the same reason, many descriptions of the Front Controller pattern on the web do not draw the distinction between a Front Controller and a Application Controller.

(www.phpwact.org)

View

nospam@example.com (chnghia) — Wed, 14 Dec 2005 14:02:37 +0100

The view obtains data from the model and presents it to the user. The view represents the output of the application.

The view generally have free access to the model, but should not change state of the model. Views are only representation of the state of the model.
The view reads data from the model using query methods provided by the model.

With an Active Model, the view can register itself to receive notifications when the model changes, and the view can then present a more up to date version of the model.

Sometimes generic reusable view components can be arbitrarily connected to the model in a process known as binding.

See Template View and Transform View for strategies of implementing views.

(www.phpwact.org)

Model

nospam@example.com (chnghia) — Tue, 13 Dec 2005 14:44:29 +0100

The model encapsulates the functional core of an application, its domain logic. The goal of MVC is to make the model independent of the view and controller which together form the user interface of the application. An object may act as the model for more than one MVC triad at a time.

Since the model must be independent, it cannot refer to either the view or controller portions of the application. The model may not hold direct instance variables that refer to the view or the controller. It passively supplies its services and data to the other layers of the application.

Sea Domain Model and Transaction Script to organize domain logic.

Passive Model: With a passive model, the objects used in the model are completely unaware of beging used in the MVC triad. The controller notifies the view when it executes an operation on the model that will require the view to be updated.
The passive model is commonly used in web MVC. The strict request/response cycle of HTTP does not require the immediacy of an active model. The view is always completely re-rendered on every cycle, regardless of changes. This may be especially true in PHP where no state is retained between requests.

Active Model: In the active model, model classes define a change notification mechanism, typically using the Observer pattern. This allows unrelated view and controller components to be notified when the model has changed. Because these components register themselves with the model has no knowledge of any specific view or controller, this does not break the independence of the model.
This notification mechanism is what provides the immediate updating that is the hallmark of a MVC GUI application.

Model Adapter: It is possible to use an Adapter to add change propagation or other active model features to passive model objects, tuning a passive model into an active model.

Presentation Model: The purpose of MVC is to separate UI from domain logic. In doing so, an MVC implementation typically develops a set of reusable classes for each of concerns in the triad. Sometimes, data or behavior that firmly belongs on the user interface side of the division can conveniently be represented using the infrastructure of the model side of the division. Thus object that would appear at first glance to be in the model are really part of the interface concern, that in the view and controller.
Some examples include scrollbar positions and column sorting.
This is somtimes called an Application Model and the pattern known as MMVC after the idea that there are two separates models.

(www.phpwact.org)