www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How D may replace PHP & ASPX on the Web!!!

reply Matthew Ong <ongbp yahoo.com> writes:
Hi All,

Here are some ideas of how to position D that may actually capable of 
replacing some major web framework like PHP/ASPX.

Many PHP and ASPX sites are being used because they are easy to support
development with IDE like(ASPX) or PHP with plenty of ready made 
platforms like nuke/joomla/others... They may not be high performance
or mission critical, but they are welcome by plenty of novice developers
and also many professional one also.


I am NOT trying to sell a CRM product here, so

https://www.sugarcrm.com/crm/ondemand_eval.html

This is a rather comprehensive professionally implemented CRM coded in 
PHP. Now, SugarCRM is being use not because all web pages are CRM 
product, but to show how a professional product is implemented in PHP.

Have a look into this TOC:

https://www.sugarcrm.com/crm/support/documentation/SugarCommunityEdition/6.2/-docs-Developer_Guides-Sugar_Developer_Guide_6.2.0-toc.html

Developer Tools --> Module Builder

D in the web page rendering may wish to provide:
1) Support for international users group via a single standardize:
    1.1) standardize the locale config and switching.
    1.2) currency format
    1.3) date time format / timezone automatically calculated.
    1.4) others..
2) Support skin theme switching and customization. This will

3) Support User Logins and ACLs of Menu and web forms. There is
    a build in session tracking ability. There should be at least
    these type of user control level:
    - Admin (administrator of website, aka super user)
    - back office staffs (simple non-it staff that can)
    - registered user (provide login/password/registration)
    - public user

4) Support customization of forms and also building new module on the 
fly. See: Developer Tools --> Module Builder in sugarcrm below.
    Those modules can be easily develop on one machine and zip up for 
exporting to another machine via uploads.

5) Allow developer to paste in new code updates into some form of hooks 
that connects to a form post or button events. Business Logic Hooks.
https://www.sugarcrm.com/crm/support/documentation/SugarCommunityEdition/6.2/-docs-Developer_Guides-Sugar_Developer_Guide_6.2.0-Sugar_Developer_Guide_6.2.0.html#9003722

6) Support Extension like plugins to be developed.
7) Support multiple platforms including some mobiles
    devices.

This is NOT to say that other people will not be permitted to use D to 
build a web framework, but if there is a compilable and working 
reference implementation that demonstrate such abilities, it will point
D web developers to the right directions.

That document is easy to read and also has already a working product 
along with data samples to play around with.

Because PHP is a runtime interpreted language, the module builder is 
able to create sometime on the fly during development. However, I do
see that D already has this ability with the new TryNow buttons.

The whole idea about building a programming language is to have many of
adoptions by the developers and is visible by plenty of end users that 
does not know nor care about programming language. But, they will 
recommend to others.

PHP server if you do not have one installed already.

https://www.sugarcrm.com/crm/download

pick the FastStack Installer.
http://www.sugarcrm.com/crm/download/helper.html?dl=/frs/download.php/8274/sugarcrm-CE-6.2.1-windows-installer.exe


Love to hear some comments about this one.

-- 
Matthew Ong
email: ongbp yahoo.com
Jul 18 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
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.
     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.
 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. 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.
 Support customization of forms and also building new module on the

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.)
 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! 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.
Jul 18 2011
next sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
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.

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.

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.

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

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.)

 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 yahoo.com
Jul 19 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Matthew Ong
 The KEY idea that I am trying to suggest is the modeling of the D Web
 Framework that could beat google go

Go's offering for web apps is very, very poor (at least it was last I checked when they did that "web apps in go" advertisement). It seemed content with offering only the bare minimum. D is already much better.
  The framework itself should be a single pid within the OS.

Why? Note btw: D already has this. My cgi.d can be used with an embedded http server, meaning all data is handled by a single process. But I recommend against it because that's less robust. If the one process dies, everyone suffers. It also doesn't scale as well as a multiple process approach, but this is surely my implementation more than anything else. There are things I kinda like about single process, but the robustness is a huge hit against it.
  Browser site time format might
 allow hacker to mess the time info of attacks.

No, you still use one time format inside the app. Timezone translation is only done for user input and output.
 I actually in favor the Microsoft asmx + aspx approaches here, but
 the aspx and asmx must be within the same SINGLE PID memory space.

It looks like that has a lot in common with web.d. In web.d, you implement a service like this: === class MySite : ApiProvider { int add(int a, int b) { return a+b; } string sayHello(string name) { return "Hello, " ~ name ~ "!"; } } === If you're in the same process, you can call the functions directly: === auto api = new MySite(); assert(api.add(1, 2) == 3); === It's just a regular class, so you call methods normally if you're local. If you are on a remote server, a very similar interface lets you call the functions remotely. Javascript example: MySite.add(1, 2).get(alert); // calls alert(3); You can also do other languages, nested calls, custom formats, etc. Anyway, this is super fast if local - it's just a method call - and reasonably fast and accessible if remote, while giving nice looking code. It gets really cool when you start using enums, alias, and structs though.
 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.

Meh, those fancy sites tend to work worse in my experience.
 I am on +0800GMT what time zone you are on?

I'm at GMT - 0400
Jul 19 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 7/20/2011 1:24 AM, Adam Ruppe wrote:
 Matthew Ong
 The KEY idea that I am trying to suggest is the modeling of the D Web
 Framework that could beat google go

Go's offering for web apps is very, very poor (at least it was last I checked when they did that "web apps in go" advertisement). It seemed content with offering only the bare minimum. D is already much better.

   The framework itself should be a single pid within the OS.

Why? Note btw: D already has this. My cgi.d can be used with an embedded http server, meaning all data is handled by a single process.

 But I recommend against it because that's less robust. If the one
 process dies, everyone suffers.

This is what I have in mind with three processes: 1) Httpd with thread pools that handles multiple request and respond including web services. 2) Login/ACL/SessionID handling process that can do IPC(No network) and logs some activities. Routinely save the sessionID info into a file base database. Interact with (1) for authentication and session. 3) Monitoring (1) & (2) using some IPC to probe both the process health and may execute some garbage collection instructions.
 It also doesn't scale as well as a multiple process approach, but
 this is surely my implementation more than anything else.


 There are things I kinda like about single process, but the
 robustness is a huge hit against it.

   Browser site time format might
 allow hacker to mess the time info of attacks.

No, you still use one time format inside the app. Timezone translation is only done for user input and output.
 I actually in favor the Microsoft asmx + aspx approaches here, but
 the aspx and asmx must be within the same SINGLE PID memory space.

It looks like that has a lot in common with web.d. In web.d, you implement a service like this: === class MySite : ApiProvider { int add(int a, int b) { return a+b; } string sayHello(string name) { return "Hello, " ~ name ~ "!"; } } === If you're in the same process, you can call the functions directly: === auto api = new MySite(); assert(api.add(1, 2) == 3); === It's just a regular class, so you call methods normally if you're local. If you are on a remote server, a very similar interface lets you call the functions remotely. Javascript example: MySite.add(1, 2).get(alert); // calls alert(3); You can also do other languages, nested calls, custom formats, etc. Anyway, this is super fast if local - it's just a method call - and reasonably fast and accessible if remote, while giving nice looking code. It gets really cool when you start using enums, alias, and structs though.

email it to me for testing? Show me how to setup, perhaps we can take it further into better level. I am new to D, but have seen many enterprises environment. Does the webservices give some thing like this or a proper WSDL? http://www.webservicex.net/ws/wscatlist.aspx Another thing: The java script works on IE, Chrome and firefox? If yes, that is great. If not, please have generate WSDL that can allow java/.NET/PHP to interact with. That will open up the D WebFramework integrations. I am currently working for a purely .NET environment company and can have resources to test that out. Java and PHP is free.
 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.

Meh, those fancy sites tend to work worse in my experience.

 I am on +0800GMT what time zone you are on?

I'm at GMT - 0400

-- Matthew Ong email: ongbp yahoo.com
Jul 26 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Matthew Ong wrote:
 Are you able to zip up those into a single file that is
 compilable and email it to me for testing?

http://arsdnet.net/apidemo.zip go into the demo folder and run: dmd apidemo.d -J. arsd/web.d arsd/dom.d arsd/cgi.d arsd/sha.d It will build a CGI file by default. Drop it into your cgi-bin on apache or make one on IIS and you can run it. (I've tested this program on Windows Vista IIS and Linux Apache so it should work for you too)
 Does the webservices give some thing like this or a proper WSDL?

No. Might not be hard to add though, but it's not something I've wanted so I haven't done it.
 The java script works on IE, Chrome and firefox?

Yes. I've also written code so you can access the functions from PHP and Bash shell. It's not hard to write more language access to it.
Jul 26 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Robert McGinley wrote:
 That is a framework that is an http server
 with url mapping instead of a cgi library.

You should take a look at the zip in my last post: http://arsdnet.net/apidemo.zip The way my web.d works is it builds on top of cgi.d to do that url to object mapping. class SiteDemo : ApiProvider { // found at / Document _defaultPage() {... } // this method is at /hello string hello(string name) { return "hello, " ~ name; } // this object is at /SomeObject/ID class SomeObject : ApiObject { this(SiteDemo a, string id) {} } // this is at /SubObject/ class SubObject : ApiProvider {} } cgi.d is actually more than just cgi - it also works fine with fastcgi or an embedded http server. (the embedded needs add on modules netman.d and httpd.d from http://arsdnet.net/dcode them compile with -version=embedded_httpd My httpd.d is single threaded though, so I don't recommend using it in production at this time. But, if you deploy on Apache or IIS, it's easy to do that, and just a recompile to switch backends later if you want. Don't have to edit your app.)
Jul 27 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Just being brief here, but something web.d can actually do right
now that might be cool is plugging in modules to build your site.

====
import arsd.web;

import some_blog_module;
import some_forum_module;

class MySite : ApiProvider {
     alias SomeBlogModule blog;
     alias SomeForumModule forum;
     alias _sitemap sitemap;
     Document _defaultPage() { redirect("sitemap"); return new Document; }
}
mixin FancyMain!MySite;
====

If some_x_module existed, that would compile and run a site with:

/ -> redirect to /sitemap -> which is an automatically generate
tree of links of all site functions.

/forum -> the Forum object
/blog -> the Blog object


Those sub-objects can be completely independent, and still
integrate into your site with ease!


I actually fairly hate web services. The whole idea strikes me
as rather blarghy; my data is mine, and I really don't want you
to have it.

But, the main alternative is downloading some app then spending
hours trying to integrate it into the rest of your site.

Ever tried to build a coherent site out of WordPress, PHPBB,
some other thing and custom code on top of it? I have. Pain in my
ass, even if I'm willing to take some shortcuts.

Each one has their own login function. Each has their own styles
and template systems. Each has their own user database. And, of
course, each has their own code that can't be brought together.
Try including a Wordpress file in phpbb. You'll wanna slit your
wrists.



The beauty of the web.d approach here is that those modules
are now brought into your class, with the magic of alias.

That means they share a number of fundamental functions!


Providing a _getGenericContainer on the outer level can apply
to those inner classes. Your _postProcess is run even on the
inner class methods.

What that means is styling them is fairly trivial - it automatically
puts the content inside the skeleton you provide, and your
modifications after-the-fact are still done.

(_postProcess() can be thought of a way of a server side
alternative unobstructive javascript - it presents you with the
final DOM tree and you can modify it as you see fit before the
output is written.

_getGenericContainer is the starting point - when building a
final document, it calls that to get a reference to a specific
place in your HTML template as to where to put the main content.)



If that isn't enough, you can still use inheritance to override
methods in the provided classes, or to add more. Or, you can
call their methods directly. No need to mess with some php plugin
to auto post to the forum, just call forum.makePost() directly.



One question comes to mind: what if you need to add configuration
to those modules? Can't do that with alias.... or can you? If
the modules were templates...

alias SomeBlogModule!(config, info) blog;

that should work right now. One point of power might be to pass
typeof(this) as a template arg, so it can access your top level
class' special methods. Using template constraints, it can let
you know what you need to implement for best results. Some good
interfaces might be getLoggedInUser() and getDatabaseHandle() to
make integration that much easier.


Some questions remain: what about stylesheets? If you write
websites like I do, the .css file is a necessity. Adding it in
the postProcess section could work. Or, something I've really
liked doing recently is this:

======
void _catchAll(string path) {
     if(path == "/style.css") {
           cgi.setResponseContentType("text/css");
           cgi.setCache(true); // unlimited client side caching
           cgi.write(import("style.css"));
           return;
     }
     super._catchAll(path);
}
====


That is - serve up the css file from inside the application. It
makes deployment slightly easier, and I can concatenate data
on the server if need be:

string style = import("style.css");
version(special)
    style ~= import("other-style.css");
cgi.write(style);


This concatenation is what you can do with child objects.
If ApiProvider had a style() method, you could call it for each
child.

Then, of course, overriding it or providing another stylesheet
later on or with greater specificity gives you full control,
along with sensible defaults.

I think I'll add this as a standard thing soon. (like how
"functions.js" is built in to web.d to provide the JS api. Just
link to that name from your template html and you can use all
your D functions via AJAX type calls.)


All we've gotta do is write up some of these modules and see if
the idea works as well in practice as I hope!
Jul 27 2011
next sibling parent reply Kagamin <spam here.lot> writes:
Adam D. Ruppe Wrote:

 I actually fairly hate web services. The whole idea strikes me
 as rather blarghy; my data is mine, and I really don't want you
 to have it.

You don't want customers for your site? BTW real software like PHPBB processes the customer's data, not your.
Jul 28 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Kagamin wrote:
 You don't want customers for your site?
 BTW real software like PHPBB processes the customer's data, not your.

I have no idea what you're talking about.
Jul 28 2011
prev sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
On 7/28/2011 12:57 PM, Adam D. Ruppe wrote:
Hi Adam,

 I actually fairly hate web services. The whole idea strikes me
 as rather blarghy; my data is mine, and I really don't want you
 to have it.

If you look at this diagram: http://download.oracle.com/docs/cd/A60725_05/html/comnls/us/pjm/oapps.gif Many different modules within an enterprise levels applications may need to be able to exchange information with each others. Sale Force Automation is most likely something like: SugarCRM/MS Dynamic CRM. Financial will be using something like Oracle as ERP. Supply Chain/Manufacturing software might be SAP. They all will have some exchange data among themselves from various physical locations and various physical servers behind different firewalls. SOA (Webservices / JMS/ MQ) is used with XML for data information sharing for such purposes. TIBCO is one of the major application that does just that. http://download.oracle.com/docs/cd/A60725_05/html/comnls/us/pjm/oapps.gif BizTalk Server from MS is also within this segment of market. Applications that are build on JAX-WS + strut / asmx + aspx MVC model are very much welcome and accepted in various industry because that replaces the very old RPC and EAI + Middleware approaches. Hopefully you might consider doing something about it for even PHP has some form of Webservices support. -- Matthew Ong email: ongbp yahoo.com
Jul 29 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Matthew Ong wrote:
 Hopefully you might consider doing something about it for even PHP
 has some form of Webservices support.

I've already done it, for both client and server. The point of that last post is I want an easy to use *alternative* using the same code. HTTP web apis aren't as easy to use as D inheritance.
Jul 29 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/29/11 9:09 AM, Adam D. Ruppe wrote:
 Matthew Ong wrote:
 Hopefully you might consider doing something about it for even PHP
 has some form of Webservices support.

I've already done it, for both client and server. The point of that last post is I want an easy to use *alternative* using the same code. HTTP web apis aren't as easy to use as D inheritance.

Adam, you've shown great virtuosity with D, web apps, and your framework. Do you think you'd consider packaging your work as a proposal for inclusion in Phobos? Andrei P.S. Hi again everyone... I've been busy with work and then sick. I'm still busy, but feeling better now.
Jul 29 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:
 Do you think you'd consider packaging your work as a proposal
 for inclusion in Phobos?

Yeah, once it's nailed down. Right now though, the "design"* is still volatile and the implementation pretty ugly. There's some weird limitations too (Nick has started helping to fix these though, so this situation will probably change rapidly) so not suitable for the stdlib at this point. * I say "design" because it's actually more of an evolution of "hey that might be cool" tempered by a handful of small real apps using it than an actual "this is a good idea" design. cgi.d might be phobos ready though with some documentation. I've started writing that up a week or so ago. Started using github too, so check out the README here to see what I have documented so far: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff I spend more time on "Why?" in documentation than "how" though! But that's because I tend to believe that libraries represent and added cost in general, so the benefit really needs to be justified for every little hassle it puts you through. With some luck, once you understand why I did it the way I did, the usage will be easier to remember too, since you can always go back to these principles rather than memorizing a list of functions.
Jul 29 2011
prev sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
On 7/27/2011 1:33 AM, Adam D. Ruppe wrote:
 http://arsdnet.net/apidemo.zip

 go into the demo folder and run:

 dmd apidemo.d -J. arsd/web.d arsd/dom.d arsd/cgi.d arsd/sha.d

Could you also show me how to do configuration within Vista IIS and also Apache? I have not done both server for a long while. Getting old... :) -- Matthew Ong email: ongbp yahoo.com
Jul 29 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Matthew Ong wrote:
 Could you also show me how to do configuration within Vista IIS
 and also Apache?

Search for the header CGI setup: http://arsdnet.net/web.d/cgi.d.html
Jul 29 2011
prev sibling parent reply Matthew Ong <ongbp yahoo.com> writes:
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.

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 

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!"

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: ongbp yahoo.com
Jul 26 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Matthew Ong wrote:
 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.

Yeah, this is why web.d does envelopeFormat=json and format=json in addition to document/html. If you can return proper data structs or objects, it will work well without extra effort. If you want to do more customization, it also has a Page function that can return a Document.
 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.

Those costs aren't too big, but what you described is how FastCGI works. FastCGI is supported by my cgi.d code without needing modification in your app code. Just recompile.
Jul 26 2011
prev sibling next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
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
Jul 19 2011
prev sibling next sibling parent Robert McGinley <mcginley.robert gmail.com> writes:
Hi all,
New to D and the mailing list.  I'd actually like to see something =
closer to CherryPy for D.  That is a framework that is an http server =
with url mapping instead of a cgi library.  Not a fan of apache (true I =
could use Nginx).  I think it would have great application in highly =
scalable web apps.  (Much better then compiling PHP into C++ and then to =
machine code ala Facebooks HipHop.)
Rob


On Jul 26, 2011, at 1:33 PM, Adam D. Ruppe wrote:

 Matthew Ong wrote:
 Are you able to zip up those into a single file that is
 compilable and email it to me for testing?

http://arsdnet.net/apidemo.zip =20 go into the demo folder and run: =20 dmd apidemo.d -J. arsd/web.d arsd/dom.d arsd/cgi.d arsd/sha.d =20 =20 It will build a CGI file by default. Drop it into your cgi-bin on apache or make one on IIS and you can run it. (I've tested this program on Windows Vista IIS and Linux Apache so it should work for you too) =20
 Does the webservices give some thing like this or a proper WSDL?

No. Might not be hard to add though, but it's not something I've wanted so I haven't done it. =20
 The java script works on IE, Chrome and firefox?

Yes. I've also written code so you can access the functions from PHP and Bash shell. It's not hard to write more language access to it.

Jul 27 2011
prev sibling parent Robert McGinley <mcginley.robert gmail.com> writes:
Ah, That makes sense I'll have to play around with it.
Rob
On Jul 27, 2011, at 1:52 PM, Adam D. Ruppe wrote:

 Robert McGinley wrote:
 That is a framework that is an http server
 with url mapping instead of a cgi library.

You should take a look at the zip in my last post: http://arsdnet.net/apidemo.zip The way my web.d works is it builds on top of cgi.d to do that url to object mapping. class SiteDemo : ApiProvider { // found at / Document _defaultPage() {... } // this method is at /hello string hello(string name) { return "hello, " ~ name; } // this object is at /SomeObject/ID class SomeObject : ApiObject { this(SiteDemo a, string id) {} } // this is at /SubObject/ class SubObject : ApiProvider {} } cgi.d is actually more than just cgi - it also works fine with fastcgi or an embedded http server. (the embedded needs add on modules netman.d and httpd.d from http://arsdnet.net/dcode them compile with -version=embedded_httpd My httpd.d is single threaded though, so I don't recommend using it in production at this time. But, if you deploy on Apache or IIS, it's easy to do that, and just a recompile to switch backends later if you want. Don't have to edit your app.)

Jul 27 2011