WebDNACodeSparker FRAMEWORK by Govinda

I am glad to help the beginners. I am not sure if WCS (WebdnaCodeSparker) really will make it easy for beginners or not. It seems to me that what it does do well is take care of some desired things, that a developer will eventually want in their projects: like having SEO-friendly (clean) URLs, exact control over what URL loads what logic code.. which in turn loads what HTML template,... caching,... white space-control,... etc. But make it easy to start for beginners? I dunno.

numero = 313
interpreted = N
texte = Remember when we were beginners? ... how it felt when we were first trying to even sort out the difference between client-side and server-side? At that stage of someone's understanding, I think it might even make sense to encourage them to go ahead and mix webdna and HTML all into one simple file after another.. until they get the hang of it. At that early stage 'MVC' is just another (headache) layer of abstraction that can break the camel's back, as the saying goes. I would encourage beginners to use WCS in case *they know they want* the feature set of WCS... but otherwise I would say, "wait until you appreciate why you would want that feature set, from first-hand experience". Eventually one gets tired of un-tangling Spaghetti code. ;-) ... eventually one wants their URL to be clean for various reasons.
Get WebDNACodeSparker

Watch the Video Tutorials at WebDNACodeSparker

"WebDNA Code Sparker" framework - Intro./Background "WebDNACodeSparker" framework - demo - MVC - 3 parts "WebDNACodeSparker" framework - demo - URLrouting - 2 parts "WebDNACodeSparker" framework - demo - Caching - 3 parts "WebDNACodeSparker" framework - demo - How to Install - 2 parts "WebDNACodeSparker" framework - demo - Environments "WebDNACodeSparker" framework - demo - White-Space Control "WebDNACodeSparker" framework - demo - Debugging "WebDNACodeSparker" framework - demo - Utilities "WebDNACodeSparker" framework - talk - Future of WebDNACodeSparker Anyway I would be glad to make another video or two or more.. but let us discuss this some more. When I read you say, 'Please make a demo on "searching".', I think, "Well searching in WCS is the same as it ever was in Webdna. You just use a [search]...[/search].". See, I do not see what the question really is.. if there is one. Perhaps you are saying the beginner might not know *where* to put their [search]...[/search] code? Then I would say, "watch the demo video on 'MVC', and see if you still have a question.. and then articulate that question as well as you can... and then we'll see what I can answer". People may wish (for simpler projects) to just put their [search]'s right into their Controller files, as they build up the [text] variables which become the HTML output containers that populate their View files (the HTML templates). Or for more elaborate or complex projects/code, I suggest putting the [search]'s into the Model files, which are loaded by the Controllers, in the init section at the top, so that you can keep your Controller code succinct and *easy to read*.. so that, for example, if you wanted to get the HTML output that results from some search.. and put those results into a variable in your Controller, then you could, for example, just put this into the Controller:
[text]buildingUpArtShowReport=[buildingUpArtShowReport]Here's all the paintings with blue sky motifs:[fn_MODEL_Artists get=skies&type=blue&artist=(all)][/text]
(and in the 'M_art.dna' Model file, is where you would have defined the [fn_MODEL_Artists] function.. and where lives the actual [search]...[/search]. See how this ^^^ Controller code is easy to read, and might help keep a long complex Controller file from getting difficult to read or deal with? This (example just above) *is* what a "search" might look like in a Controller file. This is the kind of thinking behind WCS.. and talking about this kind of design is how I envision helping people who wished to use it, beginner or not. If I just say, "To search, do this: [seach]...[/search]..." , then what have I really offered special, over and above the official docs? Same kind of thing comes to mind when I read your other suggestion for a new demo video on "[function]s" Functions are functions. What is the question? I would say, "See the official docs for an explanation of what functions are and how to use them." If you mean, "How are functions used in WCS?" The answer is, "Same as anywhere." But what I WOULD ADD is that: in WCS, for clarity and ease of code maintainability, you define your functions *in the places that makes sense to do so*. The first two URL segments after the domain (in the actual URL, or else in a re-routed URL) determine the Controller file and Controller "method" (function) that fire. Now let us consider those function which are not those immediate controller/method functions: these auxiliary functions are usually best loaded in a Utility file, or else in a Model file, tucked away so that these function definitions do not clutter your Controller code where you would just place the *calls* to the functions.. ; your Controller code is where you just want to keep the code succinct with respect to your business/application *logic*. Remember when we were beginners? ... how it felt when we were first trying to even sort out the difference between client-side and server-side? At that stage of someone's understanding, I think it might even make sense to encourage them to go ahead and mix webdna and HTML all into one simple file after another.. until they get the hang of it. At that early stage 'MVC' is just another (headache) layer of abstraction that can break the camel's back, as the saying goes. I would encourage beginners to use WCS in case *they know they want* the feature set of WCS... but otherwise I would say, "wait until you appreciate why you would want that feature set, from first-hand experience". Eventually one gets tired of un-tangling Spaghetti code. ;-) ... eventually one wants their URL to be clean for various reasons.

Get WebDNACodeSparker


Watch the Video Tutorials at WebDNACodeSparker



"WebDNA Code Sparker" framework - Intro./Background







"WebDNACodeSparker" framework - demo - MVC - 3 parts
















"WebDNACodeSparker" framework - demo - URLrouting - 2 parts











"WebDNACodeSparker" framework - demo - Caching - 3 parts
















"WebDNACodeSparker" framework - demo - How to Install - 2 parts











"WebDNACodeSparker" framework - demo - Environments






"WebDNACodeSparker" framework - demo - White-Space Control






"WebDNACodeSparker" framework - demo - Debugging






"WebDNACodeSparker" framework - demo - Utilities






"WebDNACodeSparker" framework - talk - Future of WebDNACodeSparker






Anyway I would be glad to make another video or two or more.. but let us discuss this some more. When I read you say, 'Please make a demo on "searching".', I think, "Well searching in WCS is the same as it ever was in Webdna. You just use a [search]...[/search].". See, I do not see what the question really is.. if there is one. Perhaps you are saying the beginner might not know *where* to put their [search]...[/search] code? Then I would say, "watch the demo video on 'MVC', and see if you still have a question.. and then articulate that question as well as you can... and then we'll see what I can answer".

People may wish (for simpler projects) to just put their [search]'s right into their Controller files, as they build up the [text] variables which become the HTML output containers that populate their View files (the HTML templates). Or for more elaborate or complex projects/code, I suggest putting the [search]'s into the Model files, which are loaded by the Controllers, in the init section at the top, so that you can keep your Controller code succinct and *easy to read*.. so that, for example, if you wanted to get the HTML output that results from some search.. and put those results into a variable in your Controller, then you could, for example, just put this into the Controller:

[text]buildingUpArtShowReport=[buildingUpArtShowReport]
Here's all the paintings with blue sky motifs:
[fn_MODEL_Artists get=skies&type=blue&artist=(all)]
[/text]


(and in the 'M_art.dna' Model file, is where you would have defined the [fn_MODEL_Artists] function.. and where lives the actual [search]...[/search].

See how this ^^^ Controller code is easy to read, and might help keep a long complex Controller file from getting difficult to read or deal with?

This (example just above) *is* what a "search" might look like in a Controller file. This is the kind of thinking behind WCS.. and talking about this kind of design is how I envision helping people who wished to use it, beginner or not.

If I just say, "To search, do this: [seach]...[/search]..." , then what have I really offered special, over and above the official docs?

Same kind of thing comes to mind when I read your other suggestion for a new demo video on "[function]s" Functions are functions. What is the question? I would say, "See the official docs for an explanation of what functions are and how to use them."
If you mean, "How are functions used in WCS?" The answer is, "Same as anywhere."

But what I WOULD ADD is that: in WCS, for clarity and ease of code maintainability, you define your functions *in the places that makes sense to do so*. The first two URL segments after the domain (in the actual URL, or else in a re-routed URL) determine the Controller file and Controller "method" (function) that fire. Now let us consider those function which are not those immediate controller/method functions: these auxiliary functions are usually best loaded in a Utility file, or else in a Model file, tucked away so that these function definitions do not clutter your Controller code where you would just place the *calls* to the functions.. ; your Controller code is where you just want to keep the code succinct with respect to your business/application *logic*. Govinda

DOWNLOAD WEBDNA NOW!

Top Articles:

Related Readings:

5. Writing Files

How to write a file using WebDNA...

4. Password Protecting

How to password-protect a page using WebDNA...

7. Searching Databases

Searching databases with WebDNA and conclusion...

3. Passing Data from a Form

Passing data from a form and retrieving it using WebDNA...

6. Working with Databases

Working with WebDNA database...

2. Conditional Programming

Conditional programming with WebDNA...