On 7/20/2011 1:21 AM, Graham Fawcett wrote:
On Tue, 19 Jul 2011 23:59:34 +0800, Matthew Ong wrote:
7) Support multiple platforms including some mobiles devices.
Any website that doesn't work on mobile devices already is garbage. The
whole point of the web is device independence!
True, but many many web application is currently not yet mobile ready
because they are stuck in the CGI model(Aspx/JSP/Strut) rather than the
full MVC model like asmx + aspx.
That makes no sense to me at all. What on earth does the server-side
"model" have to do with how a mobile device renders a Web page?
Furthermore, how is JSP or Strut anything like "CGI", and how is "MVC" an
alternative to "CGI"?
If there is value in your post, I think you are obscuring it by making
confusing statements like these.
Pointing at a CMS or a set of diverse tools and saying, "D should have
something like this!" is not terribly productive. Perhaps you could start
by offering an itemized list of (clear, specific) features that you think
a D Web framework ought to support.
Graham
Hi Graham,
> True, but many many web application is currently not yet mobile ready
> because they are stuck in the CGI model(Aspx/JSP/Strut) rather than
>the full MVC model like asmx + aspx.
This is because most web framework only takes in standard HTTP FORM POST
type request and give browser dependent HTML/XHTML type of respond to
the caller.
Full MVC asmx + aspx will separate the View(V) logic from the Business
logic Controller(C) of handling different database table Model(M).
I suspect even SugarCRM is not handling it that way. Could be wrong,
I have yet to dig into its detail.
> Furthermore, how is JSP or Strut anything like "CGI", and how is
"MVC" an alternative to "CGI"?
I think Adam in the respond explained this part. I am in favor of a
thread pool or pre-started processes pool concepts because it takes CPU
and OS time to load new process and new thread it memory and CPU queue.
Nothing to do with D it is more like OS behavior. However, how that is
modeled will impact how each request and respond is handled. What I am
not suggesting is that there is only one PID per web application
instance. There can be an external monitoring process to restart the
pool of threads if the main pool crashes. Sorry for not being too clear
about this in previous posting.
> Pointing at a CMS or a set of diverse tools and saying, "D should have
> something like this!"
My apologies, what I do see is existing PHP developers taking existing
framework and hack it to be deployed for the client as a customized
projects. Eg: Joomla, PhpNuke, and others. However, PHP does not defines
this as part of PHP standard web framework.
What I can see is those feature that I have highlighted some really
useful build in facilities within a known product.
Perhaps you may want to setup a simple pre-can sugarCRM and play
with it to see what are the facilities already in there.
What I am not for is to direct copy from sugar but rather see what model
are good to keep and re-innovate and what part is not good and re-innovate.
--
Matthew Ong
email: [email protected]
