close ad
Databridge V2 with MySQLi support IS Now Available!
open ad
View Menu

Technical Support Forums

Free, outstanding support from WebAssist and your colleagues


My WA Framework Feedback and Suggestion whistlist

Thread began 8/11/2010 3:49 pm by victor278184 | Last modified 8/13/2010 5:58 pm by Ray Borduin | 1846 views | 12 replies |


My WA Framework Feedback and Suggestion whistlist

Hello, i made a purchase for this Framework, i found this extension is very potential.. keep up the good work.

however for my first day of test, i found several thing need to improve with this extension

1. It's not support with pure php code.
i create a php file with only <?php echo "TESTING"?> and include the plugin on my test.php. The Result : TESTING is everywhere.. on Title, on Head, on Body.

i hope you can add REGEX filtering, if no <head>..</head> found or no <title>..</title> found.. put everything on Body only.

Because when we assign plugin to a php programmer, it's highly the programmer will create only php code without manual html,head,body tag in it.

2. it Grab <meta http-equiv..>
if i use 8 plugins with simple html, this framework will include 8 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> on the head tag... this really not necessary

these are for my first hour experience.. i will updating the thread as i gain more experience using WA's framework.. i've been using ADDT since it born as MX Kollection, i build my own simple CMS system with ADDT's Include... I will be happy to port the application to WA's framework...

Great Job

Sign in to reply to this post

Ray BorduinWebAssist

1) I'm not sure if there is any benefit to using a plugin if it is pure php code. Why not just use require_once()? The whole advantage of plugins over a standard require_once() is that it will deconstruct a full page and break it into it's component pieces... updating necessary links and other references and then place it into the correct corresponding location on your page. If it is pure php it wouldn't know whether that code belongs in the head or the body, so you would have to place it manually to the correct location.

In your case you could still use it, but you would want to delete the header and title references from the page that are automatically placed, since you aren't using them.

It probably is a bug though. Technically they should all three be blank and you should have to refer to the ->Contents of the plugin to return a result since there is no head, body, or title defined. I'll log a bug to get this fixed.

2) Remove the meta information from plugins where you don't want it added... you could also remove the head reference and instead add the css and scripts individually as well as just the meta from the plugin that you want to actually use. In order to keep it simple we include the entire head, which will include meta information if the plugin page has it. If multiple plugins have meta information, there is no way to prioritize which should or shouldn't be used, so it would have to be a human decision at some point. It seems the easiest route would be to simply remove the meta tags from plugin pages where you don't want or need them.

I will log a feature request to add a binding for "Header without meta" and to ask if you want to include the meta information when applying each plugin. This would allow you to make that decision during application more easily instead of having to remove the meta tags from the plugin pages beforehand.

Sign in to reply to this post


1) the big advantage for developer to use this framework is the "path" correction... usually we use folders to "seperate" template and code... i'm not talking about MVC concept.. but a quick ('n dirty) approach like this is usefull to create quick project.

so instead of debuging from main site, we could concentrate on each module and combine it into one in index.php

2)Yes, i agree the solution is to remove unwanted head element manually, but i think most of WA's user are visual designer who take a lot of advantage using 'instant' (and great) solution with WA's extension... probably not many aware of this 'bug'

Sign in to reply to this post


My Third Finding notes

Let me add another capabilites of ADDT's Includes compare WA's Framework... this is not a bug, but rather a major wishlist.

3.) Variables Reference/Scope

for example i have define a variable in main file:



the a.php will have plugin b.php

echo "data from a.php is : ".$data;

the $data is empty.
i tried using : "global $data" but yet still empty.

in ADDT, there's no problem to have a global variable scope between "master to slave" page

web developer who use templating system, as they can use recordset that can be assign to variable and can be use by entire plugin. a master variable controller.

hope this can also consider for future update... this will be a great feature !

Sign in to reply to this post


Victor: Let me weight in here if you don't mind. You gave me quite a fright, as this is a feature I will be relying on - so I did a quick test, and think I found what is happening, and how to correct it.

First: As much as I love ADDT Includes I find the WA Plug-ins are actually better. Here is why!

ADDT Includes always included the file at it's "include position". The head was never extracted and placed at the head of the main document. Therefore queries were being run from within the body, not within the head. New Document declarations were beign added half way down the body - etc... etc... Pretty ugly when you view source, but it seemed to work.

WA did it right in my opinion! They include the file at the very top of the page, then just insert the body at the place you want it to show. THIS IS MUCH BETTER because the head data will actually be included in the head!

So why doesn't your variable work?
Simple. The file is being included, parsed and stored before your variable is set! Make sure the WA PlugIns are done AFTER your variable - and everything will be fine. PlugIns are added to the top of the page - so you will need to move them down to a location below your variable. Or course, if your variable is calculated inside the body of A, that could be a problem, you may need to re-think a couple of things and define all your variables earlier. It's all in the load order. Load your variable before the page is included and the page will inherit it. (remember, the display of the body is NOT where the page is loaded. The load is at the top)

ADDT always seemed to get the variable, only because it always loaded really late.

Personally - I prefer this system and look forward to re-thinking a couple of things to make it work. It will be cleaner in the end.

Sign in to reply to this post


Once thing WA might want to consider is changing the placement of the "include code" it produces.

Rather than insert it at the top of the page, maybe it should be inserted just before the <HEAD> of the page. That way all code that is created before the head (Recordsets, custom code, variables, included functions, etc... etc...) will automatically be available to the included page without the need to move the code there manually.

Sign in to reply to this post

Ray BorduinWebAssist

It should actually already be placed at position "99"... which should be the very last thing before the <html> tag... and should still be below any recordsets and custom code.

Right before the <head> is problematic since templates will have that region locked.

I think you are right about your advice above. The variables will pass through, but they need to be above where the plugin is called, not just before the body is displayed.

Sign in to reply to this post


@codamedia - Thanks for joining this discussion, i believe we both are on the same path of porting our ADDT Includes to WA Include.. it will be a great "journey" ahead.

@ray - The tips given by codamedia is great and it would be better if you put on the manuals or tips/trick section... i believe it would be helpful for our fellows WA's developer.

Sign in to reply to this post


Fourth Notes - 404 Redirection

this will be simple but yet quite helpfull feature: 404 Redirection

usually developer will use parameter that act as controller. in ADDT, the developer put nice 404 redirection if the document not found.

what do you think ray ?

Sign in to reply to this post

Ray BorduinWebAssist

Let me understand the feature...

You want to be able to specify another plugin to use in case the plugin it tries to use isn't found?

That seems easy enough.. probably only applicable for dynamic plugins and dynamic themes. Is that what you are thinking? If so I'll log it as a bug and try to get it into a dot release.

Sign in to reply to this post

Build websites with a little help from your friends

Your friends over here at WebAssist! These Dreamweaver extensions will assist you in building unlimited, custom websites.

Build websites from already-built web applications

These out-of-the-box solutions provide you proven, tested applications that can be up and running now.  Build a store, a gallery, or a web-based email solution.

Want your website pre-built and hosted?

Close Windowclose

Rate your experience or provide feedback on this page

Account or customer service questions?
Please user our contact form.

Need technical support?
Please visit support to ask a question





Ease of use


security code refresh image

We do not respond to comments submitted from this page directly, but we do read and analyze any feedback and will use it to help make your experience better in the future.

Close Windowclose

We were unable to retrieve the attached file

Close Windowclose

Attach and remove files

add attachmentAdd attachment
Close Windowclose

Enter the URL you would like to link to in your post

Close Windowclose

This is how you use right click RTF editing

Enable right click RTF editing option allows you to add html markup into your tutorial such as images, bulleted lists, files and more...

-- click to close --

Uploading file...