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


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


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


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 yahoo.com
Jul 19 2011
next sibling parent reply 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
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.


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


That is great news.


   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.


CGI is ok. I played with CGI back in the days of perl in unix+apache httpd.


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


If there is way of handling the session from

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.


Are you able to zip up those into a single file that is compilable and
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.


They did not model it properly. Perhaps D community could.



 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 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?


=20
 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?


=20
 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?


=20
 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
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
next 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
prev sibling 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.


http://download.oracle.com/docs/cd/A60725_05/html/comnls/us/pjm/ovpjm.htm

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


Thanks very much, I will download and tries this out.

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