Vote: to unify, or not to unify (Was "RE: Business Logic in Cocoon Applications?")

[Derek Hohls <DH...@csir.co.za>]

My Vote is for A; with a "comment text" that says:

- if there are any "best approaches" that are case-specific these
must be clearly pointed out to the users ...

... bear in mind that even though some users may be Cocoon "newbies"
they may be experienced developers in other frameworks and want to
know how to handle "case x" - "user tracks" based on needs and 
experiences would be extremely powerful if we can get that far!

>>> dleangen@canada.com 2004/05/04 09:56:29 AM >>>

[I don't want to barge in on things here or step on anybody's toes. My
intention is only to get some direction so I can help contribute to
the
Cocoon documentation. Although I am a relative newbie any my Cocoon
skills
are 1/1000th of the vets lingering around on this list, I think that's
exactly what qualifies me to help contribute to the user
documentation.]


The first thing that we need to decide on is: do we aim for a unified
approach, or should the platform continue to be a testing ground? Or
rather,
what is the "face" of Cocoon that we want to show to its users?

There are good arguments for either case, but until we decide on which
path
to take, it is difficult to get started with any useful tutorial or
other
that explains how to program biz logic in Cocoon.


In my view, regardless of what's happening internally, the user doc
should
show a simple and unified approach to using Cocoon. Otherwise, it's
just too
long and difficult to get a real project up and running, especially for
the
non-seasoned developer. Anything else can (and should) be reserved for
more
advanced users.

If there's anything I learned in the commercial world, it's that the
message
must be simple and easily understood, even if it's not perfect from a
theoretical standpoint. I therefore strongly suggest orienting user
documentation with simplicity and user centricity in mind.


However, we still need to reach consensus on what such a unified
approach(es) should be.


I would like to take a poll (probably the first of many):

***********************************************************

 [  ]  A. I think that we should show users the "best" way
          to get up and running with Cocoon.

 [  ]  B. I think that we should show users all the options
          possible and let them decide the best approach.

 [  ]  C. Yeah, whatever. Either way is good for me.
          Peace, man!


Poll results so far:

  A. - 1
  B. - 0
  C. - 0


***********************************************************



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org 
For additional commands, e-mail: users-help@cocoon.apache.org 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Vote: to unify, or not to unify (Was "RE: Business Logic in Cocoon Applications?")

[go...@osmosis.gr]

> 
> However, we still need to reach consensus on what such a unified
> approach(es) should be.
> 
> 
> I would like to take a poll (probably the first of many):
> 
> ***********************************************************
> 
>  [  ]  A. I think that we should show users the "best" way
>           to get up and running with Cocoon.
> 
>  [X ]  B. I think that we should show users all the options
>           possible and let them decide the best approach.
> 
>  [  ]  C. Yeah, whatever. Either way is good for me.
>           Peace, man!
> 
> 
> Poll results so far:
> 
>   A. - 1
>   B. - 0
>   C. - 0
> 
> 
> ***********************************************************
> 
> 

i think that there in NO BEST way. every aproach is releated with what the 
needs are.so the end-user can choose the right for him/her.

--stavros

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org 
> For additional commands, e-mail: users-help@cocoon.apache.org 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org