How D may replace PHP & ASPX on the Web!!!

[Matthew Ong]

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: ongbp at yahoo.com