On 7/19/2011 2:00 AM, Adam Ruppe wrote:
Matthew Ong wrote:
Now, SugarCRM is being use not because all web pages are CRM
product, but to show how a professional product is implemented in PHP.
Yes, I've had to work with it's code before... it was so brutally
slow and overcomplicated that we ended up deciding to just throw
more hardware at the problem instead! It was moderately painful
hooking it into the external application too. Blargh.
Yes. I am well aware that PHP is slow because of 3-tier approaches.
The KEY idea that I am trying to suggest is the modeling of the D Web
Framework that could beat google go. It is about how many build in
ability within the existing framework that is shown here in SugarCRM
as a single example for discussion points for what may needs to be in
the new Web framework from D. Not as a product to be build by a developer.
PHP by itself is rather primitive, it does not have all those feature
listed in my previous message. However PHP developer has nuke, joomla,
sugarcrm... already there to ride on top off.
D is currently not the case, I think.
A single post pass over http server, next php engine before it reaches
the core processing of the application. It actually passes via at least
2 process id runtime before the request is ever handled.
What I am showing here is Not to use the SugarCRM over all architecture,
but rather, build a list of supported nice features
directly within the webframework in D.
What would be nice is the D- Webframework itself will provide a minimum
http/s secure server to serve the framework and can be configure within
the framework. The framework itself should be a single pid within the OS.
That way, a single request is only handled within one single pid process
all the way until the response packet. Not doing the traditional CGI
approaches. But more like the Java Tomcat JSP approaches in the
framework level. JSP is slower than D because of JVM. So, DSP(D version
of JSP) would be processed within a single PID.
1.3) date time format / timezone automatically calculated.
What I did for timezone was to use a little javascript to set a
cookie based on the users' local clock.
Incredibly simple and worked very well.
That is needed within the logic of the server to track data for security
purpose and also tx time. Browser site time format might
allow hacker to mess the time info of attacks.
2) Support skin theme switching and customization. This will
With my D sites, I was able to express the vast majority of changes
in css, and the rest through a DOM post-processor and separate
template directories when appropriate.
Skin in PHP Joomla & SugarCRM uses css and images within a well-know
layout and also name. This is a nice feature that may be adopted to ease
designers for customizing and deployment.
The post-processor is the special thing - most apps treat templates
as strings, which maybe could do these things, but I doubt it'd be
as clear and easy as with the higher level structures.
I actually in favor the Microsoft asmx + aspx approaches here, but the
aspx and asmx must be within the same SINGLE PID memory space. A single
asmx code to be call within the same DSP process without soap-xml but
when the asmx code is call without the process, soap-xml is used.
SEE: http://msdn.microsoft.com/en-us/magazine/cc163674.aspx
By using asmx as the controller and call direct (NO Soap-xml) by view
from within the SAME process, things can happen really fast. When a call
to controller from outside the process it uses Soap-Xml. That way, we
can separate the testing and also integrations to other languages.
http://www.asp.net/mvc/tutorials/understanding-models-views-and-controllers-cs
Support customization of forms and also building new module on the
fly.
web.d attacks this by letting you alias in other classes to your
main app, and of course, with dom templates editing forms is easy.
5) Allow developer to paste in new code updates into some form of hooks
web.d exposes your public functions via javascript, which makes this
pretty simple.
When I integrated sugarcrm with my D application, I used web.d's
javascript functionality and a standard onclick handler to bring
the D functions in very easily. Dealing with PHP made it harder
than it had to be, but it was still pretty simple.
(that thing goes both ways btw - web.d's functions are easily accessed
with a small PHP library too, that uses curl.)
I am in favor of asmx model. See the explanation above.
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.
BTW: I started writing a higher level explanation of my cgi.d.
http://arsdnet.net/web.d/cgi.d.html
Still a work in progress, of course. Once it's done, I'll write
a similar document for web.d.
Good job, modeling the right approach will position the framework for
success. With the GUI like form base creation of webform of SugarCrm
where all the backend code handles the database creation and also
default HTTP IO handler code. Programming D on the web may change
how D development market is structured in the future.
FYI, come up with something catchy for your framework. It helps to get
attention.
I am on +0800GMT what time zone you are on?
--
Matthew Ong
email: [email protected]
