Data Access Layer - Is there a real seperation?

[Brenden Vickery]

Really? I've never seen anything written in the principles of OOP that says a class must not have more than 'n' methods or 'n' properties, so as far as I am concerned that rule does not exist and so I choose to ignore it. It is an artificial rule designed by someone who likes to add complexity to the problem.

Its quite possible that Im wrong in everything Ive said in this thread however if you are interested in learning different ways or teaching your way you are going to need to come up with arguments to support your opinion that have more substance than "Ive never read anything that says that so as far as Im concrened youre wrong".

The definition of encapsulation is quite clear - all the properties and methods for an object must go into a single class.

Deciding what methods and properties belong to which object is where I think youve gone wrong.

My presentation layer is not tied to my database, nor is my business layer. The only layer which has physical communication with any database - by using the database APIs - is my data access layer. I am therefore able to switch from one dbms engine to another simply by switching the component in my data access layer. This is what the 3-Tier architecture is all about, and I have implemented it correctly.

If it comes to changing the structure of a table by adding or removing fields, then I agree that I have to make changes in my presentation and business layers, but such changes are extremely small being limited to adding or removing a field name from a simple list.

This is NOT a weakness in my design, it is a fact of life. You cannot write a business object that does not have knowledge of the data it has to work with, nor can you write a presentation layer that does not have knowledge of which fields to place where, and with what HTML control. It is simply not possible to write software which does not have knowledge of which fields exist in the database, therefore changes in the physical structure of the database will require changes in the software's knowledge of the database.

I have worked with several languages over the past 20 years that have used data dictionaries (aka application models) where the dictionary is a representation of the physical database. It is imperative that the dictionary and the database are kept synchronised - if you make changes to one without making corresponding changes to the other the software will fail.

What I have done is to place a mini data dictionary within each business object which simply contains the database engine name, the database name, the table name, and a list of fields. So if I change the physical structure of the database I must also change the data dictionary.

Can you change the name of a form element and not make any changes in the data access layer?

Can you change the name of a column in the database and only change the 'data dictionary' in one place?

Wrong! I have components of sql statements in my presentation layer, but these are not built into complete queries until they are processed within my DAO. If a different DAO needs to organise those components in a differet way, then that is handled within the DAO and is completely invisible to both the presentation and business layers.

Its code like this im refering to (person_list.php):

$table_id = 'person';                   // table name
$title    = 'List PERSON';              // form title
$screen   = 'person.list.screen.inc';   // file identifying screen structure
$button_text = 'Person';

// identify extra parameters for a JOIN
$sql_select = '*';
$sql_from   = 'person '.
              'LEFT JOIN pers_type ON (person.pers_type_id = pers_type.pers_type_id)';
$sql_where  = '';

// set default sort sequence
$sql_orderby = ''; 

This is not the data access layer.

What happens if you change the name of the person table? Does this code need to be changed?

What happens if you change the pers_type_id column name? Does this code need to be changed?

What happens if you change the way a person is related to a person type in the database? Would this code need to be changed?

Maybe I didnt see the code that would make these changes but if your answer to any of these questions is yes then your layers are mixed up.

I never claimed that my entire infrastructure was OO, just my business and data access layers. I have a lot of procedural functions because there is absolutely no benefit in making them non-procedural. They work just fine as they are, and they would not work any better if I changed them, so why change them? 'If it ain't broke don't fix it' is an old, wise saying that comes to mind.

Putting "class Default_Table {" before a list of procedural functions and "}" after the list does not make the code Object Oriented.

Surely it will not reduce te amount of code, but simply move it from one large class to a series of smaller classes. But then I will have to have extra code to instantiate and communicate with these extra classes, so the end result will not be LESS code but MORE code, and more complex code at that. I think I shall ignore your advice and stick to the KISS principle.

The end result will be less code, but not until you refactor.

[MickoZ]

Done. I've added a FINISH button to the relevant screens.

Why you name it "FINISH", maybe that is what the "expert" was talking about... An user might think that "Finish" mean you conclude it...

Yes, the navigation information is stored in the session data, and I have seen it happen a few times over the years, but I can never reproduce it on demand

Open a new browser, that doing a new session.

Go directly there:
http://www.tonymarston.co.uk/sample/person_add.php

There navigation is gone... :\

Maybe that is why people use a front controller *g*

[McGruff]

I choose to keep all my properties and methods for an object in a single class because that is what encapsulation is supposed to be about. This means that whenever I want to change that object I only have a single class to maintain. If I had that information spread over several different classes it would not only be more difficult to maintain, and would be more complex to deal with as I would have to flit from one class to another in order to get anything done.

Yes: more classes are difficult to design because you have to think hard about how to accurately represent their relationships - but not quite so hard as you might otherwise have had to since we have the benefit of years of patterns research. This stuff is important.

Tightly honed classes create a system which is in fact easier to maintain precisely because they are tightly honed. If you get that right, at some point you find that instead of writing swathes of new code for every task, you can often simply aggregate existing classes in a new way.

http://c2.com/cgi/wiki?CouplingAndCohesion

Lean & mean classes should also be easier to test.

[lastcraft]

Hi...

A User object should represent one user, no more, no less, and should encapsulate the properties and responsibilities of the real-life object.

It's unfortunate that User has been bounced around, because I always get suspicious when I see one of these, either as a class or as a table. Sometimes it is disquised as Subscriber or Customer, but the effect can be the same. User doesn't have a clearly defined role. It's more of a relationship between an external entity, usually a person, and the system. Often this name is used for a login mechanism initially, but other stuff, such as contact, account and payment details get added later. Because the concept is a bit vague it gathers functionality like a sponge. The data model starts to look like a star network, all emanating from the "User". One day you want to add multiple accounts to a single Party (Person or Company) and the god "User" bites back with a vengance.

These days if the concept of a User can be described quite adequately as Login or AccessKey and Authorisor (my current favourite) then I'll go that route. If there is contact details to be added later then I will likely add them as an Account and then split that later if accounts can have shared contact info. Something like...

Party (Person or Company) (1)<-->(*) Account (1)<-->(*) AccessKey

Access key is both the username and password together on that kind of system, but may be an MD5 key on a SOAP server or a token from an SSH keychain.

I have only once needed all entities (Party, Account, AccessKey), but it's nice to have a clear refactoring route when things start to get complicated.

User <-> UserMapper ( <-> DAO ) <-> Database

That's the one . With the arrows signifying visibility (dependency)...

User --> UserAccessor --> Database
User <-- UserMapper --> Database
User (ActiveRecord) --> Database.

That switch of visibility is the distinguishing feature. The trick of turning ActiveRecord into DataMapper and so switching the arrow is known as DependencyInversion.

Also if you are doing a mostly passive data (i.e. reporting or CRUD) application then also...

Widget --> ResultSet, Connection --> Database

Because you only have one domain object (ResultSet) all of your display code can be written just once. This is the Delphi/VB client-server approach and is spectacularily efficient if the domain logic that can affect the flow of code is limited.

yours, Marcus

[lastcraft]

Hi...

Any opensource that we can look at?

Er...no .

Actually we are developing a slimmed down persistence layer which I have shown to a few selected people. You can have a private copy if you are interested. The current project owner (Mike Mindel you hero) has agreed it to be open sourced and we should be publishing it shortly. It's more of a proof of concept right now than a working system and we want to do some more refactorings before we go completely public.

yours, Marcus

[lastcraft]

Hi...

If you add a property which is an unknow type (not a date, int, text or whetever field) so far, then you will have to alter your view-logic at less... it is common sense.

For straight forward CRUD apps, yes.

For a tiered app. adding a field to a view would require a method on an application object (also common sense of course).

That method could do a calculation from other information though. It could aggregate information from completely different domain objects (for example a shopping basket view adding shipping costs). It could do lot's of things. What it does at the domain level should be shielded from the view.

As we descend further, even if it was just adding a new property of the domain object we should still not know the table schema. So it could be joined in from another table, a stored proc, or maybe it's not even in a relatonal database (an image say). The schema is invisible from just looking at the domain objects' interfaces.

The definition of tiering is that each tier can only see the one immediately below. The full architecture is sometimes called 4-tier (Presentation, Application, Domain, Infrastructure), but there are slightly different interpretations. When Application and Domain are combined, that is the traditional 3-tier. I find the 4-tier model a better diagnosis tool, although tiering (layering) is a pattern and as such you adjust it to taste.

Anyway, if changing the DB schema causes a change to the view you obviously don't have tiering. If changing a view (without adding a new application feature) causes anything at all to change then you don't have tiering. If changing a domain interface causes the schema to be edited even though the relationships are essentially correct, then you don't have tiering.

Except that things aren't that simple.

In practice we take some shortcuts if they are expedient. An example is making the table names and class names synonymous (called an isomorphic mapping). This can make the architecture easier to understand on the ground and can save mapping code. If we are the only application or domain library using the DB then there is no problem with this. If a problem does arise, then you will have to put in the mapping code.

As an aside, once you get low enough in the architecture it's not actually that easy for developers to do much damage to a project. As long as the presentation is safely isolated then the refactoring work can often be done in a matter of days even in the face of a complete about turn. For example changing a DataMapper architecture to a DataAccessor one took 4 pair/days on a previous project.

Summary:
Yes you have to make it logically possible for a new piece of information to be displayed. Tiering allows us to choose the "how" of that process with complete freedom. You don't have to add a corresponding database field.

yours, Marcus

[lastcraft]

Hi...

In this example I would not have the User class send an email. Instead I would have a controller which extracts the relevant information from the User class, then passes that information to an email object.

It means that the email address becomes a public field and the means of communication becomes visible in the client code. Here is a simpler solution...

$contact = &$person->getContact();
$contact->send($message); 

With this arrangement even the means of communication is hidden. It could be an instant messenger or SMS service for example.

class User {
public $id;
public $date;
public $username;
public $password;

public function __construct() {
}
public function get() {
}
public function insert() {
}
public function update() {
}
public function delete() {
}
...
public function get_param( $param ) {
return $this -> $param;
}
} 

In my infrastructure if I add or remove fields from the database all I have to amend within the class is the $fieldspec array which contains the list of field names. I do not have to amend any other class properties or methods at all.

Yep, that's TableDataGateway and RowDataGateway munged together into one class. The result of this is the overloaded class name. That explains why I couldn't make sense of the client code posted earler.

You have a client/server app., not a three tier one.

My business layer objects are only connected to the presentation layer via a controller which sucks data out of the object, converts it into XML format, then performs an XSL transformation to produce XHTML output.

Yep, it's a mostly procedural client/server library. You are using the table classes only as data structures and as a namespace for holding the finder methods. You could have leveraged the GridWidget pattern to make the view layer a whole lot more fun. TransformView (the XSL) makes it difficult for graphic designers to edit pages without developer intervention. With a TemplateView and Widgets they can be dragged around in Dream Weaver and the like.

You really, really should read the enterprise patterns books.

yours, Marcus

[MickoZ]

I never did heard the CRUD (CReate Update Delete) acronym. ;-)

I guess it depends how you work too... but of course if I go on and rename an attribut of an object... of course, we can always make this backward compatible, but sometime we will want for code understanding to rename the field everywhere. ;-)

This is often the case when you did get the vocabulary or the design wrong in the first place. But let's say vocabulary mainly, and for some reason you are picky and you want to use the good term in your attribute, etc. You will eventually want to update your view (deprecating probably the thing that let the view communicate with the old structure vocabulary, i.e. a method).

Is there one of those persistance pattern that you would suggest for beginning (I guess I tried myself some of them in a prototype of a software I am doing, but I have changed between each of my concept of coding style on purpose since it was a prototype, that of course evolved and evolved, even thought I planned rewrite since beginning and I funnily just stumbled across an article of you that talked about rewrite/fix )

However, I would like to know of a clean way. Maybe the solution for me is to study the different way that exist.

DAO, DataMappers, etc.

I want something very flexible and if possible the most simple as possible. Note: there is some complex logic/structure in the apps. It mights even go torward a R/D project ;-) that is where my client is going forward to... but if everything go success, I will probably have to do something more solid than some prototype code and I am trying to get some knowledge on building better architecture and using the intelligence that have been put in the past of course... (I like do-it-myself, but I guess more I will advance I will have to accept the time-constraint and to use what other have worked for!)

[Tony Marston]

I think letting the user select one or multiple items should be an important property (call it usability?!) And if your model is done the way I think, then it should not be a major problem adding that feature. radio != checkbox.

Excellent suggestion! I have now changed the popup screen so if only one selection is allowed the SELECT control is changed to a radio button instead of a checkbox.

[Tony Marston]

I never did heard the CRUD (CReate Update Delete) acronym. ;-)

CRUD is actually short for Create, Read, Update and Delete. It was used in a matrix to show which programs accessed which tables, and what the type of access was. It may be just as relevant now as it was 20 years ago.

[Tony Marston]

Done. I've added a FINISH button to the relevant screens.

Why you name it "FINISH", maybe that is what the "expert" was talking about... An user might think that "Finish" mean you conclude it...

FINISH means I've finished with this screen, go back to the previous one. It is similar to the CANCEL button in those screens which allow updates via a SUBMIT button. I don't want to name it CANCEL as that means 'cancel this update and go back to the previous screen'. I don't want to call it BACK as the behaviour is totally different from the browser's BACK button. Perhaps I should call it CLOSE instead?

The trouble is that different people like different words, and there is no way to please everybody.

[Version0-00e]

TransformView (the XSL) makes it difficult for graphic designers to edit pages without developer intervention. With a TemplateView and Widgets they can be dragged around in Dream Weaver and the like.

You really, really should read the enterprise patterns books.

Forget about the web designer for a moment, are you suggesting Lastcraft that XSL stylesheets are an hinderance in anyway? I use XSL stylesheets frequently myself and find them useful

I've used the Template View pattern (and Composite View) and I find that likewise you can put logic in a database, you can also put (certain) logic in a stylesheet. This helps to simplify things some what, and to a degree, gives easier maintenance.

[lastcraft]

Hi...

I use XSL stylesheets frequently myself and find them useful

It's just a very different way of doing things. If the skills to manipulate them exist within the design department/person then no problem. If it's in house work then it's not usually a problem either, because the different people can sit together. If the display side of things often changes radically then you accept this as a compromise.

If you are mainly displaying tables and lists only then having a Widget to do the job makes sense. If you have that arrangement then the transform view complexity can be pushed into the Widget, simplifying the presentation.

They have trade-offs and you weigh them against each other at the time.

yours, Marcus

[Tony Marston]

Really? I've never seen anything written in the principles of OOP that says a class must not have more than 'n' methods or 'n' properties, so as far as I am concerned that rule does not exist and so I choose to ignore it. It is an artificial rule designed by someone who likes to add complexity to the problem.

Its quite possible that Im wrong in everything Ive said in this thread however if you are interested in learning different ways or teaching your way you are going to need to come up with arguments to support your opinion that have more substance than "Ive never read anything that says that so as far as Im concrened youre wrong".

I am not saying that you are wrong, I am just saying that people keeping throwing new rules at me that do not exist in the OO tutorials that I have studied. Different groups of developers seem to come up with different additions and interpretations to the basic principles of OOP, and because I do not share these 'opinions' I see no reason to abide by their 'rules'.

Some developers seem to think that directly accessing class variables breaks encapsulation, but see these articles for a contrary view:

• Encapsulation is not information hiding
• Abstraction, Encapsulation, and Information Hiding

Do you also agree with the person who says that Inheritance breaks Encapsulation?

Deciding what methods and properties belong to which object is where I think youve gone wrong.

That is simply your opinion which I do not share. My infrastructure conforms to the principles of the 3-tier architecture, so my business objects have all the properties and methods they need to act as intermediaries between the presentation and data access layers. You may implement the 3-tier architecture in a different way, but as long as it fulfills its purpose it would be a perfectly valid implementation, just as mine is a perfectly valid implemenation. I would not complain that your implementation was invalid just because your implementation was different. It would only be invalid if it did not fulfill its purpose.

Can you change the name of a form element and not make any changes in the data access layer?
Can you change the name of a column in the database and only change the 'data dictionary' in one place?

If I make a change to the physical database then I must make a change to the business layer so that it knows how to deal with that change. If I add a field to the database which requires certain validation rules, where do I put those rules? In the business layer. Likewise if I remove a field from the database then I must remove any rules for that field from the business layer, otherwise it will try to validate a field that does not exist.
Similarly my presentation layer, which is responsible for building all the HTML screens, *must* have some knowledge of what fields need to be displayed, in what order, with what labels and with what controls. You cannot add a field to the database and have it magically appear in the relevant screen exactly as you, or the user, want it. If you can then I would love to know your secret.

I have components of sql statements in my presentation layer, but these are not built into complete queries until they are processed within my DAO. If a different DAO needs to organise those components in a differet way, then that is handled within the DAO and is completely invisible to both the presentation and business layers.

Its code like this im refering to (person_list.php):

$table_id = 'person';                   // table name 
$title    = 'List PERSON';              // form title 
$screen   = 'person.list.screen.inc';   // file identifying screen structure 
$button_text = 'Person'; 

// identify extra parameters for a JOIN 
$sql_select = '*'; 
$sql_from   = 'person '. 
              'LEFT JOIN pers_type ON (person.pers_type_id = pers_type.pers_type_id)'; 
$sql_where  = ''; 

// set default sort sequence 
$sql_orderby = ''; 

This is not the data access layer.

No, and nor are they complete sql statements. They are components of sql statements which are passed to the DAO in pieces, and it is up to the DAO to form them into complete sql statements according to the whims of the DBMS engine with which it deals.

Actually, I am not totally happy with that way of doing things, but my problem is this: by default each business entity can only access a single table, but certain transactions which access that business entity may require it to perform either a simple or a complex JOIN. Therefore it is the choice of transaction which governs which JOIN statment to use. As the transaction is a presentation layer component the request for a particular JOIN must come from the presentation layer, pass through the business layer, and be executed by the data access layer. I could get the presentation layer to say "give me join number 21", but I'm even less ahppy with that idea. How would you handle this in your infrastructure?

Putting "class Default_Table {" before a list of procedural functions and "}" after the list does not make the code Object Oriented.

I beg to differ. If I write code that uses the OO functions within PHP, and that code follows the basic principles of OOP and exhibits the properties of encapsulation, inheritance and polymorhism, then by its very nature that code is OO.

That may not be the proper way according to your rules, but it works! In my humble opinion it is far better to have something which breaks some arbitrary set of rules but which works than it is to have something which obeys those rules but which fails to work.

[Tony Marston]

Open a new browser. Go directly to: http://www.tonymarston.co.uk/sample/person_add.php

The navigation area is gone... :\

Ah, I see now. The problem is that the menu and navigation buttons are constructed by the parent screen which you have bypassed, which is why they are not there. If you start from the start of the transaction hierarchy, instead of the middle, there would be no problem.

[Tony Marston]

I choose to keep all my properties and methods for an object in a single class because that is what encapsulation is supposed to be about. This means that whenever I want to change that object I only have a single class to maintain. If I had that information spread over several different classes it would not only be more difficult to maintain, and would be more complex to deal with as I would have to flit from one class to another in order to get anything done.

Yes: more classes are difficult to design because you have to think hard about how to accurately represent their relationships - but not quite so hard as you might otherwise have had to since we have the benefit of years of patterns research. This stuff is important.

Tightly honed classes create a system which is in fact easier to maintain precisely because they are tightly honed. If you get that right, at some point you find that instead of writing swathes of new code for every task, you can often simply aggregate existing classes in a new way.

If, as you say, many small classes are more difficult to design than a smaller number of larger classes, and the effort of creating these many classes does not produce any measurable benefit, then, as a faithful follower of the KISS principle I choose to bypass unnecessary complexity and produce simple code that works.

I have worked on a system where the architects chose to have ten layers of abstraction instead of three, and guess what! It was a total disaster as far as the developers were were concerned. It was so complicated and difficult to debug that it took weeks to build even a single component. The client was so impressed that he cancelled the project. I built ny own version of the same architecture, but restricted myself to only 3 layers instead of 10. The developers loved it because they could produce components in hours instead of weeks.

So my personal experience of systems with more layers than necessary is that they are to be avoided like the plague, and I'm afraid that my personal experience outweighs everybody else'e opinions by a large margin.

[Tony Marston]

If you add a property which is an unknow type (not a date, int, text or whetever field) so far, then you will have to alter your view-logic at less... it is common sense.

For straight forward CRUD apps, yes.

For a tiered app. adding a field to a view would require a method on an application object (also common sense of course).

So you agree that adding a field to a view requires changing the business object to recognise and deal with that new field. And by definition you must add it the database otherwise its value will be lost.

Then why do you and others keep telling me that if I cannot change my database schema without changing my business and presentation layers then I don't have tiering?

If I add a field to the database then I must change the view otherwise it wont't be displayed. I must also change the business layer otherwise it won't be validated.

FYI adding a new field to a view in my infrastructure does not require adding a new method to a business object.

If changing a view (without adding a new application feature) causes anything at all to change then you don't have tiering. If changing a domain interface causes the schema to be edited even though the relationships are essentially correct, then you don't have tiering.

Except that things aren't that simple.

In practice we take some shortcuts if they are expedient.

So you are allowed to take shortcuts then? I take shortcuts to keep things simple and easy to maintain. That is why I do not waste my time with unnecessary bloat.

Yes you have to make it logically possible for a new piece of information to be displayed. Tiering allows us to choose the "how" of that process with complete freedom. You don't have to add a corresponding database field.

If you add a new field to a screen, but do not store the user's data in a corresponding new field in the database, then how is the user expected to retrieve the data that he keyed in?

[Tony Marston]

In this example I would not have the User class send an email. Instead I would have a controller which extracts the relevant information from the User class, then passes that information to an email object.

It means that the email address becomes a public field and the means of communication becomes visible in the client code.

So what? The email address has to be visible somewhere otherwise how else can it be input and maintained?

With my approach all the User class does is satisfy a request for data, and what happens to it after that is a matter for the controller which may pass it to a view of its choosing. That data may be output to a screen, written to a PDF file, used in an email message or added to a SOAP request. Surely how the user data is processed is not a function of the User class itself, but of a separate view object?

You have a client/server app., not a three tier one.

By making such a statement you have just demonstrated a complete lack of understanding of the purpose of the 3-tier architecture. Let me enlighten you: The 3-tier architecture has its application logic split across the following tiers (aka layers):

• Presentation logic = User Interface, displaying data to the user, accepting input from the user.
• Business logic = Applying business rules, ensuring the data is valid before being pased to the database.
• Data Access Logic = Database Communication via the relevant API's.

Having a separate data access layer means that you can switch from one DBMS engine to another without changing any logic in the other layers.

Having a separate presentation layer means that you can change your user interface without having to make any changes in your business or data access logic.

The 3-tier architecture was promoted in the language I used prior to PHP as it made it possible to have an application with a client-server interface and to enable it for the web simply by adding on a new HTML interface which could share all the existing business and data access logic.

In case the significance of this has escaped you, it means that a 3-tier applicaton has exactly the same structure whether it has a client-server interface or a web interface, or even if it has both at the same time. You do NOT have one version of the 3-tier architecture for client-server and another version for the web. It is the same architecture, but with different presentation layers. As my presentation layer produces HTML output and runs off a web server, it is most definitely a web application.

TransformView (the XSL) makes it difficult for graphic designers to edit pages without developer intervention. With a TemplateView and Widgets they can be dragged around in Dream Weaver and the like.

If a graphic designer's skills are limited to Dreamweaver and exclude the hand-coding of XHTML, CSS, XML and XSL then he is not much use in my book. If he cannot produce efficient HTML and CSS for his designs then he is next to useless. If he does not know XML and XSL then he is not keeping abreast of current developments.

[MickoZ]

FINISH means I've finished with this screen, go back to the previous one. It is similar to the CANCEL button in those screens which allow updates via a SUBMIT button. I don't want to name it CANCEL as that means 'cancel this update and go back to the previous screen'. I don't want to call it BACK as the behaviour is totally different from the browser's BACK button. Perhaps I should call it CLOSE instead?

The trouble is that different people like different words, and there is no way to please everybody.

Indeed it is hard to please anybody, but I guess there is word that are (from our standard usage) more appropriate. (Sometime standard usage is wrong and is not logical too, bleh!)

I think CLOSE is not bad. That is a part of the reason why I suggested that the choice be repeated too...

If it was repeated:

- no choice and click the action bouton = put no choice in the field
- no choice and want one, choose one than click the action bouton
- 1 previous choice and you don't want to change it... click that action bouton (whetever name, maybe keep the choose only).
- 1 previous choice and don't want it (an option to take no choice at all (radio or a bouton that unselect)
- 1 previous choice and you want to change it, change it and click the action bouton...

I guess I pretty much covered it. It may annoy people to get pragmatic and give suggestion but I guess it can be a good idea, since in your apps, what you try to do is give a generic way to do all similar operation (which is very interesting but hard to please everyone and HARD to please all possibility)

[Tony Marston]

I've used the Template View pattern (and Composite View) and I find that likewise you can put logic in a database, you can also put (certain) logic in a stylesheet. This helps to simplify things some what, and to a degree, gives easier maintenance.

That is exactly why I use XSL stylesheets, as the logic for deciding how to build a control for a field is maintained with the XSL stylesheet (the view component in MVC). All my business logic has to do is supply a value for each field and identify what control to use. It therefore becomes simple to say "display this field as a dropdown list, and this field as a radio group". As the construction of each control is defined within a single XSL template which is shared by all my XSL stylesheets I have managed to avoid the duplication of large amounts of XSL code. Can you do the same thing with other templating systems?

[Tony Marston]

I use XSL stylesheets frequently myself and find them useful

It's just a very different way of doing things.

Exactly. There is no single way which is right. There are many ways to choose from, each with their own sets of advantages and disadvantages, and provided that the chosen method works and both the developers and the end users can live with the advantages and disadvantages, then all in the garden is rosy.

Except, it appears, when it's MY garden when I am vilified for daring to be different. My motto is "innovate, don't immitate", so I will always look for a different way, a better way. If some people regard me as a heretic for daring to question their view of the universe, then so be it.

[Version0-00e]

Can you do the same thing with other templating systems?

Yes I can with class(es) I developed earlier this year. I can post the script if you want with some samples, once I find them that is

The original design had a few failings I admit though the redesign solved the problem. In fact I was searching for the thread I had started originally for the script to post on this thread but couldn't find it

I still feel your apparant MVC design is flawed in some way or another though I can give a big thumbs up for what your doing with XML and XSL stylesheet at least

[Tony Marston]

I still feel your apparant MVC design is flawed in some way or another

How can that be? I found numerous sources on the internet which described the principles of MVC, and I wrote code which adhered to those principles. My implementation may be different to everybody else's, but surely no design pattern, which includes MVC, is tied to a particular implementation?

[MickoZ]

Ah, I see now. The problem is that the menu and navigation buttons are constructed by the parent screen which you have bypassed, which is why they are not there. If you start from the start of the transaction hierarchy, instead of the middle, there would be no problem.

Yesterday when I first gave you the problem, I indeed passed thru the first screen! And I guess esssion timed out and that happened or something like that.

Of course that part of your apps is mainly for an "admin section" or a data management section. In a public website, we cannot 100% force the user to pass thru the admin screen, unless you redirect the person to the first screen if the session is not open, etc. There is always a way to do it ;-)

[MickoZ]

Excellent suggestion! I have now changed the popup screen so if only one selection is allowed the SELECT control is changed to a radio button instead of a checkbox.

Selections: select all | unselect all
---------------------------------------
For "single choice popup"

You should have the option:

Selections: select none (which is similar to unselect all which you may want to keep) but select all has no sense in that context (if that is easy to define those behavior from the CONTEXT, then it is worth to at less remove the select all and maybe put a more appropriate label for the unselect. "unselect choice" who know. ;-)

Also the validation of the popup force you to select something and give the error "Nothing has been selected". That is just a thing to considerate and I cannot say it is wrong or bad. However if some popup are for optionnal choice, I would like the submit to accept a "no choice" as input data, but that is probably a trivial change in your apps/validation.

After doing those kind of change, all you have to do is to make something that allow people to drag and drop component, etc. I wonder if Microsoft.Net has bring its VB feel (probably with their event driven, that I know they did) with .Net editor...