• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Guidance in choosing a pattern

 
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm trying to learn patterns by myself which in my opinion is a daunting task in itself. I have a few programs that I intend to build but I'm not sure if I've chosen the right pattern or how to implement it since I'm still at the level of where does the main go (I know a program can have multiple mains) when I worked on a project that used MVC.

The first is a simple scientific calculator. Think calculator within a windows system. How can I apply MVC to this? I undestand the view would be what the user sees, the model would be the actual computation, but the controller I get lost on.

Also, with these patterns, are they being used in conjunction with other patterns because many times that pattern itself doesn't seem to be able to stand on its own two feet so to speak.

I have books to reference, though they may not be the best, they are free and currently in my possession:

Patterns in Java Volume 1 Second Edition by mark Grand
J2EE Design Patterns by Crawford and Kaplan

Any help would be greatly appreciated.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well for a calculator, the J2EE Patterns book probably won't be of much help. Now Head First Design Patterns would be a huge eye opener for you to help you learn patterns and how to choose them.

The Controller is the controlling force, the handler of Actions, the mover of Model to View. So to speak. So if a button is clicked the Controller should handle it and change the Model.

Hope that helps in some way. First check out HF Design Patterns book.

Mark
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Matt Kidd:
I'm trying to learn patterns by myself which in my opinion is a daunting task in itself. I have a few programs that I intend to build but I'm not sure if I've chosen the right pattern or how to implement it since I'm still at the level of where does the main go (I know a program can have multiple mains) when I worked on a project that used MVC.



if you are using MVC and have multiple main!!! i will have a heart attack in that situation.


The first is a simple scientific calculator. Think calculator within a windows system. How can I apply MVC to this? I undestand the view would be what the user sees, the model would be the actual computation, but the controller I get lost on.


You don't need MVC for this. Reason Calculator doesn't have model. But just to give you a quick overview,
(1) At any point and time when you start calculator it would be single instance per jvm.
(2) Count buttons, how many are there on a scientific calculator?
(3) If you are interested in supporting other calculator types, count how many types of calculators you have?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udayan Patel:
Calculator doesn't have model.



That's not true. If you do MVC with a calculator, the Model likely will contain the current result and methods to to calculations on it.

The Controller will handle user input - react to button and key presses, and translates them into method calls on the Model and the View.

The View simply shows the current state of the model and the input gadgets (which the Controller reacts to).

Does that help?
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


That's not true. If you do MVC with a calculator, the Model likely will contain the current result and methods to to calculations on it.

The Controller will handle user input - react to button and key presses, and translates them into method calls on the Model and the View.

The View simply shows the current state of the model and the input gadgets (which the Controller reacts to).

Does that help?



Ummmm! actually not, Technically speaking your model is your database. To me you need a model where you are pulling data from somewhere and storing somewhere. for a calculator, pretty much all the data is volatile as you do the calculation and data is gone as soon as you hit C/CE. All you need is bunch of static methods that takes input and returns you answer. but Hey thats just me.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udayan Patel:
Technically speaking your model is your database. ... but Hey thats just me.



Definitely that's you, yes.

Seriously, the Model is *not* the database. The Model "is" the business logic. The database typically is separated from the Model by a persistence layer.

And "a bunch of static methods"? Hell, this is the *OO* forum...
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Definitely that's you, yes.

Seriously, the Model is *not* the database. The Model "is" the business logic. The database typically is separated from the Model by a persistence layer.

And "a bunch of static methods"? Hell, this is the *OO* forum...



hummmmm have I been smoking something all these years? I don't think so. Model IS your database. to say more Domain model. and Processes!! Now thats what we call business logic. should be operating on data, and should not hold any data. thats what you call business logic. now your object Person or Employee or Customer thats what i call model, presents you with a face of database. BTW when you speak of persistence layer that prepares model for your middleware(business logic) persistence layer does not sit between your model and database it sits between your domain model and middleware.
[ December 12, 2004: Message edited by: Udayan Patel ]
 
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udayan Patel:
hummmmm have I been smoking something all these years? I don't think so.



Yes, you are a chain smoker


Model IS your database.



I think its better not to talk about the database at all while discussing MVC.

Model-view-controller:

Consider an application that needs to support multiple client types like WAP clients, browser-based clients, and so on. If we use a single controlling component to interact with the user, manage business processing, and manage the database, it affects the flexibility of the system. Whenever support for a new type of view needs to be added, the whole application will need to be redesigned. Also the business logic will need to be replicated for each client type.

As a solution to this problem, the model-view-controller (MVC) architecture divides applications into three layers -- model, view, and controller -- and decouples their respective responsibilities.
The model represents business data and operations that manage the business data. The model notifies views when it changes and provides the ability for the view to query the model about its state. Typically, entity beans would play the role of model in the case of enterprise applications.
The view handles the display styles and user interactions with the system. It updates data presentation formats when the model changes. A view also forwards user input to a controller. In J2EE applications, the view layer would include JSP and servlets.

A controller dispatches user requests and selects views for presentation. It interprets user inputs and maps them into actions to be performed by the model. In a standalone application, user inputs include text inputs and button clicks. In a Web application, users communicate by sending HTTP requests to the Web tier. Session beans or servlets would represent the controller layer.

ibm.com/developerWorks Presented by developerWorks
[ December 13, 2004: Message edited by: Adeel Ansari ]
 
Adeel Ansari
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


now your object Person or Employee or Customer thats what i call model, presents you with a face of database.



Josie Maran is the one I call supermodel. .

lets discuss the term MVC:

- your database can't be your view. view is something about presentation tier.

- your database can't be your controller. it is not going to control your application at all.

- your database can't be your model even. although model is about business logic, database is not the implementation of your business logic. but offcourse we have some checks there like, not null, unique constraint etc. and relationships.

We can say Person or Employee or Customer as business entities, not the M of MVC.

thanks
[ December 13, 2004: Message edited by: Adeel Ansari ]
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Adeel Ansari:

We can say Person or Employee or Customer as business entities, not the M of MVC.

thanks

[ December 13, 2004: Message edited by: Adeel Ansari ]



Well, you lost me here. So, I didn't get it when you say they are business entities. Didn't you represent them with something in your system and give them their own roles? I always was sure that objects in system are representation of real life things and I still am. Where as processes are something that drives those objects! Since you explained all these would you care to explain little more that, where in your idea middleware fits? To be little more explainatory, when I say middleware includes you EJB, RMI or someother type of implimetation of business logic. Having said this would you implement something like this

Class Employee {
private float totalSalary;
private float travelExp;
private float baseSalary;

public float calculateSalary() {
this.totalSalary = this.baseSalary + this.travelExp;
}
public float getTotalSalary() {

return this.totalSalary;
}
}
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Adeel Ansari:


Model-view-controller:

Consider an application that needs to support multiple client types like WAP clients, browser-based clients, and so on. If we use a single controlling component to interact with the user, manage business processing, and manage the database,.......... I think its better not to talk about the database at all while discussing MVC.



yes business processing and mange database


it affects the flexibility of the system. Whenever support for a new type of view needs to be added, the whole application will need to be redesigned. Also the business logic will need to be replicated for each client type.



Yes, you don't have to change business logic when you use MVC therefore business logic stays at middleware level. apart from your model.

]
As a solution to this problem, the model-view-controller (MVC) architecture divides applications into three layers -- model, view, and controller -- and decouples their respective responsibilities.
The model represents business data and operations that manage the business data.


Yes, DATA!!! By the way, I would not limit myself to three tiers.

ANYHOW, I still would stick with my idea of model. again I could be just me.
[ December 13, 2004: Message edited by: Udayan Patel ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udayan Patel:
Model IS your database.



Well, there certainly is a database model, but that's not what the MVC Model is referring to.

Now thats what we call business logic. should be operating on data, and should not hold any data. thats what you call business logic. now your object Person or Employee or Customer thats what i call model, presents you with a face of database.



What you describe very much seems to resemble what Martin Fowler calls an Anemic Domain Model...


BTW when you speak of persistence layer that prepares model for your middleware(business logic) persistence layer does not sit between your model and database it sits between your domain model and middleware.



Well, the business logic might run in some middleware, but that's certainly not obligatory. But if it does, I'd say that your domain model sits in the middleware.
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Well, the business logic might run in some middleware, but that's certainly not obligatory. But if it does, I'd say that your domain model sits in the middleware.



BUSINESS LOGIC IS MIDDLEWARE!!! It doesn't run into itself although it might run into message oriented middleware.

Per Martin:
Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

As, he said Application Layer and Domain Layer still doesn't deal with data directly when it comes to save it to the database it just operates on it and pass it off. I would say combining these two would be my middleware. I betcha, If you peep into his idea of Model layer, you will find what he talking about is bunch of processes operates on domain objects. I betcha he would not write something like what I wrote in my previous post (look at the code above in one of my post) The only thing that he describe differently is, he incorporated business logic to be part of domain model.
[ December 13, 2004: Message edited by: Udayan Patel ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The "model" in MVC is a more generic term than you're digging into there. It represents the current state and applicable behavior of the domain. It does not imply any persistance, communication or middleware or anything else. An MVC calculator might have only the state that you type in and compute, nothing read from or written to databases or anywhere else. The whole point of the more generic meaning is to distinguish it from the user interface. I think we can all agree it ain't Swing widgets.

The further breakdown of service layer and domain layer is an optional way to structure the model. It doesn't have to happen.

Stateless web servers have a very different flavor of model than fat Swing programs. The service layer and a layer of business objects that map very closely to database entities is pretty common in stateless stuff. I liked Martin's paper on "anemic models" because I felt an awful lot was lost in moving from a fat client to a stateless server a few years ago. A lot of intellectual entertainment anyhow.
 
Adeel Ansari
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Udayan,
you can say Employee, Personnel, etc. as a Database Model. But this model is something else. this is not the M of MVC.


where in your idea middleware fits? To be little more explainatory, when I say middleware includes you EJB, RMI or someother type of implimetation of business logic.



Yes middleware may include EJB, RMI or some other type of implementation of business logic. But I dont think we can say an entity bean or JDO classes as model. its better to say them a persistence layer. But offcourse your session beans is the implementation of your business logic. and we refer those as MVC Model

MVC Model is something which sits above your persistence layer. below the persistence layer could be your DB.

And why I said Employee, Personnel, etc are the business entities. because we map these Database entities by using Entity beans or someother API. if it confused you then you can say it as DB entities, no problem at all.

repeating the Ilja's words. Seriously, the Database is not the Model of MVC, nor the persistence layer.

cheers
[ December 13, 2004: Message edited by: Adeel Ansari ]
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Adeel Ansari:
Udayan,
And why I said Employee, Personnel, etc are the business entities. because we map these Database entities by using Entity beans or someother API. if it confused you then you can say it as DB entities, no problem at all.

repeating the Ilja's words. Seriously, the Database is not the Model of MVC, nor the persistence layer.

cheers

[ December 13, 2004: Message edited by: Adeel Ansari ]




You didn't got it! did you? I agreed that they are business entities, but still you map it to your database. the point is they are part of your object model and represent the DATA from the DATABASE. in current world you call them value object or whatever. Business logic is something that drives them. As far as I am concern, I would not put any business logic in these classes. Anyways you might want to visit the link that Ilja put out there. I am not trying to reinvent the wheel. When MVC started model used to be object model where objects hold data and behavior both therefore model considerd business logic and data. It has been evolved since. now you have this entire layer upon your model and below your model above one is called middleware and below one is called persistence layer.
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm... I snooze for a few days, wake up, and find myself in the middle of a nightmare!

If a model is a database, then do you imply that system such as peer-to-peer networks which do not technically have any persistance do not have any models?

Persistance is more of an after-thought rather than something integrated into the system. A system should not be built relying on persistance or a specfic type of persistance (read database).

What has DAO taught you?

Even if you look at the DDD book by Eric Evans, he purely describes about a business object model with one chapter or repositories. The idea is that the model is a representation of the problem in a business domain. It is optional (although almost always happens) that the whole thing is persisted. Even in Java, you implement Serializable optionally if you want to persist the object.

Back to the Calculator.

I think Ilja nailed it with his statement at the beginning.

1. The buttons on the calculator is your view. You can have different types of views - say, big calculator, paper-thin calculator, watch calculator, etc. In some cases, it can even be a Web Service that other applications can invoke.

2. The actions that initiate the calculation would be your controller. This can be an ActionEvent from your buttons or a web service call. This would be a standard API that would be exposed by A scientific calculator (Facade?).

3. The stuff that actually does the calculation would be your model. I could probably think of the number system as the model. For example, I can break the calculations into arithmetic, trigonometric, calculus, etc.

For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine. If a machine is stateless, then why need a mechanism to store the state of a system?
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sathya Srinivasan:
Hmmm... I snooze for a few days, wake up, and find myself in the middle of a nightmare!

If a model is a database, then do you imply that system such as peer-to-peer networks which do not technically have any persistance do not have any models?


I would not make a mistake comparing business application v/s technology applications. Orange v/s apple (transactional system v/s non-transactional)


Persistance is more of an after-thought rather than something integrated into the system. A system should not be built relying on persistance or a specfic type of persistance (read database).

What has DAO taught you?


Exectly, apart from your middleware


Even if you look at the DDD book by Eric Evans, he purely describes about a business object model with one chapter or repositories. The idea is that the model is a representation of the problem in a business domain. It is optional (although almost always happens) that the whole thing is persisted. Even in Java, you implement Serializable optionally if you want to persist the object.


so, I really am thinking about getting this book, atleast to find out what exectly he means by Business object model? this really made me wonder what domain objects are and where do they fit? persitance or "model"?


Back to the Calculator.

I think Ilja nailed it with his statement at the beginning.

1. The buttons on the calculator is your view. You can have different types of views - say, big calculator, paper-thin calculator, watch calculator, etc. In some cases, it can even be a Web Service that other applications can invoke.


2. The actions that initiate the calculation would be your controller. This can be an ActionEvent from your buttons or a web service call. This would be a standard API that would be exposed by A scientific calculator (Facade?).


I had no problems with this


3. The stuff that actually does the calculation would be your model. I could probably think of the number system as the model. For example, I can break the calculations into arithmetic, trigonometric, calculus, etc.



so, lets say you have classes called Arithmatic, Trigonometry and such. I am sure you wouldn't permit your basic object Number to have Number.add(to) or Number.substract(from) on them you would rather have your Arithmatic class take care of it. And it makes sense perfactly. The point is though what would you call Number and what would you call Arithmatic? are they both part of your "model"? or would you rather call Number as part of your domain model and Arithmatic as part of your middleware?


For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine. If a machine is stateless, then why need a mechanism to store the state of a system?



exectly. therefore no domain model(domain objects). you can have multiple classes with some static methods like Arithmatic.add(to, num) Arithmatic.substract(from, num). The only difference is what you call these classes. Model or middleware. How you instantiate your Arithmatic or Trigonometry is very well hashed out by factory and such.


geez-a-loo, this thread is getting fatter for no reason seems like. Well, if it is to teach me what a model is called, I am happy to accept so.
[ December 14, 2004: Message edited by: Udayan Patel ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udayan Patel:
I would not make a mistake comparing business application v/s technology applications. Orange v/s apple (transactional system v/s non-transactional)



Well, I don't think the MVC pattern makes a distinction here.

so, lets say you have classes called Arithmatic, Trigonometry and such. I am sure you wouldn't permit your basic object Number to have Number.add(to) or Number.substract(from) on them



Why not? That's exactly how it's implemented in many OO languages, for example Smalltalk.


you would rather have your Arithmatic class take care of it. And it makes sense perfactly.



Why? Isn't one point of OO *exactly* putting data and operations together?

The point is though what would you call Number and what would you call Arithmatic? are they both part of your "model"?



Well, I would.

Arithmatic as part of your middleware?



You seem to be using an unusual definition of middleware. For me, middleware is something I use, like an RMI implementation, not something I create.

See http://en.wikipedia.org/wiki/Middleware
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sathya Srinivasan:
For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine.



Well, I think it needed to at least remember the current result - not really stateless...

And than it could have those nifty "M+", "MR", "MC" buttons, etc.
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


You seem to be using an unusual definition of middleware. For me, middleware is something I use, like an RMI implementation, not something I create.

See http://en.wikipedia.org/wiki/Middleware



As i said this is getting fat for no reason. Lets say, if you were to write an ejb based system. Don't you still extend from it and implement your business logic as part of it? Doesn't your ejb component still runs as a middleware and has solution to your business problem? I am sure you are not using session beans just to pass off data to your persistence.
 
Matt Kidd
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


That's not true. If you do MVC with a calculator, the Model likely will contain the current result and methods to to calculations on it.

The Controller will handle user input - react to button and key presses, and translates them into method calls on the Model and the View.

The View simply shows the current state of the model and the input gadgets (which the Controller reacts to).

Does that help?



yep. Thats how I conceptualized it actually. My next question got answered below.
 
Matt Kidd
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sathya Srinivasan:
Back to the Calculator.

I think Ilja nailed it with his statement at the beginning.

1. The buttons on the calculator is your view. You can have different types of views - say, big calculator, paper-thin calculator, watch calculator, etc. In some cases, it can even be a Web Service that other applications can invoke.

2. The actions that initiate the calculation would be your controller. This can be an ActionEvent from your buttons or a web service call. This would be a standard API that would be exposed by A scientific calculator (Facade?).

3. The stuff that actually does the calculation would be your model. I could probably think of the number system as the model. For example, I can break the calculations into arithmetic, trigonometric, calculus, etc.

For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine. If a machine is stateless, then why need a mechanism to store the state of a system?[/QB]




Right. Since I'm modeling it after the Calculator provided by windows there would be two views, basic and scientific, that essentially make calls to the same methods. If other views were neccesary I could just add them to the View. The Web Service part went over my head as I've been out the industry for 4 years and while I know vaguely what a web service is...okay really I don't know. probably should though. But I only want entry level.

The listeners would comprise the Controller as well as shuttle data back and forth from the model which I think breaks down to just a basic method call within the listener.

And the model would be the part I actually write meaning I have to come up with the classes and methods to determine how the results from the button calls are tabulated.

Conceptually this seems really easy but when your whole academic career was built on filling in stubs writing stuff like this becomes difficult.
 
Adeel Ansari
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

Well, I think it needed to at least remember the current result - not really stateless...

And than it could have those nifty "M+", "MR", "MC" buttons, etc.



cent percent AGREEMENT.
 
To avoid criticism do nothing, say nothing, be nothing. -Elbert Hubbard. Please critique this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic