WebAssist is still with us...

[-Michele]

Finally a good news for those who still want to use Dreamweaver and need to build dynamic websites (server-side and not client-side as the competitor Wappler):

http://www.webassist.com/forums/posts.php?id=40942

[BenPleysier]

I have been using all of the lastest versions of WebAssist's extensions using MySQLi, specifically when I have had occasion to use eCart. It brings back memories of the golden past when Dreamweaver was at its height with the inclusion of the server behaviours panels. Ray has also been very helpful when I have had to use different payment gateways, sometimes spending 4 hours and charging for one. All in all, thumbs up.

Having said that, I have fallen in love with client-side processing of data. It allows for very fast data manipulation without having to traffic back and forth to the server. An added feature is that page refresh is a thing of the past. In this regard, large database tables of more than 3K records are better processed on the server-side.

I guess that in the end it's all a matter of taste.

[osgood_]

Not sure why a page refresh should be a thing of the past, its still relevant if you're processing a product details page, which uses a different page template. On the other hand if your processing some kind of form data or simple search app using client side processing is a smoother experience. I think its more a question of where to use which one rather than one being a better solution than the other.

[BenPleysier]

osgood_  wrote

Not sure why a page refresh should be a thing of the past,

Perhaps I was a bit too subtle. Let me explain: when I use client side processing, there is no need for full page refresh, hence under those circumstances page refresh is of the past.

As you can see, I never said that a page refresh should be a thing of the past.

When I say that I have fallen in love with client-side processing, I develop many sites with an Admin section For instance, where products are displayed for sale and a product is added/edited/deleted using a modal, it is great to see the list react upon the closing of the modal without going through a complete page refresh.

Edit: Added video.

[osgood_]

Ajax certainly makes the process much more user friendly in certain circumstances but not all circumstances need to be user friendly, those being where a user might expect to be taken to a new page of information.

Ajax is good for processing form information which you want to feed back to the user in the browser, its good for search apps where you dont necessarily want any page jumpiness etc and a good few more things

I wouldnt rule out server side though to get the job done.

[Oscar - Xavia Digital]

Hello!

I agree with Michele that it is good news. Using dreamweaver CC Next together with the webassist beta again we have an updated product.

Currently it is the combination I am using to build very complex websites, backends, and intranets.

I have to say that from the Mysqli extension although the updates have been scarcer have been, in my opinion, very accurate, with an updated code simple and easy to handle and updating just the modules (like ckeditor and its file manager or phpmailer) that were necessary.

I'm very interested in Ben's opinion about the use of Dmxzone (Since I've seen that you have experience with him). I am sure that I will acquire the webassist extension as soon as it goes on sale. I have become accustomed to the system of templates, to the use of plugins with framework builder, and to the code that it generates (now very simple and elegant to edit it by hand) and it would be impossible for me to live without it.

I am not so clear whether to acquire or not a subscription to wrappler as a complement. Whenever I bought dmxzone extensions in the end I ended up never using them. Now more than ever they are products that can be complementary, and not exclusive.

PROS WEBASSIST:

- Simple and easy to read, understand and edit code.

- Very friendly for SEO and construction of frontends.

- When i have to build complex intranets, helping me with code by hand. It is very easy to combine the extension of webassit with code by hand.

- The system of templates and pluging. I am simply in love with him.

AGAINST WEBASSIST:

- It is also a dreamweaver counter. The ajax capacities are few and simple. In the end I ended up programming in ajax by hand, which I have gotten used to using jquery, but it would not be any extra capacity. (The only functionality that you have to load plugins in divs).

- It works within dreamweaver, and for me it is a counter because Adobe has it very forgotten. Every time you have to update something because this obsolete Adobe simply deletes it. It is not also an agile program in terms of speed. This together with the elimination of fireworks means that if it were not for webassist, it would be out of the Adobe ecosystem.

PROS DMXZONE

- Very innovative, and excellent ajax capabilities.

- They certainly have components for many things. With a subscription you now have a good "arsenal" of components.

AGAINST DMXZONE:

- I am worried about the SEO issue regarding the construction of the frontend. I mean, I know that Google is able to read the javascript code, but the same site built with Wrappler would compete in Google on an equal footing with that same site in Dreamweaver? It's something that disturbs me.

- Hand code. As I have said many times I have to build intranets that can be complex. It is common to find actions that can not be performed with extensions. It is easy to write code by hand with dreamweaver and webassist. With the dmxzone framework, I feel completely lost. This is something I wanted to ask Ben since he has more experience. Is it possible once you learn to use it to combine it with programming by hand?

Thanks greetings!

[-Michele]

As you said, Ben is most qualified person here to answer about your questions.

For me, server-side solutions give me a feeling of greater security... to understand what I mean see this post:

https://community.wappler.io/t/hide-secure-data-connection/1412

It's easy for those who are at first to commit serious data management errors.

Another "little" problem is that the DMXzone's client-side solutions are proprietary (I mean the framework), which means that if they close, your business is over (e.g. remember InterAKT with PHAkt).

[Teodor K]

Hello Michelle,

From what I see in your posts here and in our forums I think you don't really understand how exactly the DMXzone database tools and app connect framework work. I would like to clarify that for you and for the others reading this topic and your comments.

First of all - no javascript runs on the server-side i.e. this statement is totally wrong in terms of explaining how the app connect framework functions:

build dynamic websites (server-side and not client-side as the competitor Wappler)

The whole  dynamic data processing runs on the server-side depending on your selected server model (PHP, ASP.NET or classic ASP). So, let's say you are using PHP then all the database queries, joins etc. are being processed on the server side by PHP files and PHP  functions (in this case PHP PDO).

The idea behind our tools is to separate server-side code from the front-end.

What that means?

- It means that on the front-end you only use HTML, CSS and pure javascript. No <?php functions ?> are being inserted on the page.

Then how do you get dynamic data on the page?

- You then use App Connect Framework to call the data returned by the server-side code on the server and render it on the page. This is done via javascript. The results returned from the server are processed by PHP not "client-side". The only "client-side" part of the whole process is rendering the data on the page.

But why do you do this? Why not just using <?php ?> code directly on my pages - it's how DW has done it for years and years!

- There are many reasons to do this:

• Modularity & Reusability - With the application logic completely separated from the fron-end, you have a more modular web application. Your app logic can be reused by any number of web applications (sites) and on different interfaces.
• Responsiveness - In web applications using server-side code on the front end. (i.e. how DW server behaviors work) the workflow for a user clicking a button to get data looks like this:

              The user clicks a button to get the data

              Then the browser sends a request to the server

              Then the server queries the database

              Your code performs the logic

              Then it renders data in a view

              Then the server returns the response to the user

              Finally the user sees feedback after waiting the whole time for the page to load

          With separating client-side application, from the server-side processing you can take advantage of realoding only parts of the pages, which need to be reloaded. Also, as you have the data already returned from the server - you can do client side paging, sorting or filtering and not sending requests for every page change, or letter entered in the search box.

What about the security? You say that:

-Michele  wrote

For me, server-side solutions give me a feeling of greater security...

Imagine that you <?php echo ...?> some data on a non-protected/non-restricted page. What would be the result? Everybody who has access to it will see the data rendered. Is it PHP to blame here, or is it user's fault as he didn't apply protection on his page?

With dmxzone tools, the security is again applied in the server-side code, so it is the same. If you don't secure your data then it will be accessible. So the protection is always applied on the server-side and there is nothing to worry about ...

Hope that clears the situation for you.

As for the SEO concerns - nothing will change if you are using javascript front-end framework to render the data. What could cause SEO issues is the content quality actually, not the technologies you are using.

Google doesn't care if you are using:

<title><?php echo $row_recordset['WebsiteTitle']; ?></title>

or

<title>{{WebsiteTitle}}</title>

In the code, when both get rendered by the crawler as "Fluffy kittens"

Cheers,

Teodor

[-Michele]

Ok Teodor... only a clarification, my name is "Michele" (typical Italian male name) not "Michelle" (typical French female name)... only to avoid embarrassing situations

[Teodor K]

Oops, sorry about that

Now i cannot edit my previous post anymore ..

[Oscar - Xavia Digital]

Thanks for your first-hand explanations Teodor.

One question, is it possible, for the construction of relatively complex intranets, to use handwritten code within the wrappler framework in a simple way? I do not know if it is a product that is designed for this type of work or not, we often have to program intranets that are certainly different from the concept of website and we have to write a lot of code by hand.

We are used to using dreamweaver with various extensions (we own many extensions of webassist and dmxzone) for tasks that can be done and mixed with code written by us for tasks that can not be done by extensions because they are very specific and "pecualiary".

Thank you!

[Teodor K]

I don't think of something that cannot be achieved, but could you provide an example of what was the last thing you couldn't be able to achieve using an extension and what was required to be hand-coded?

We have customers building really complex intranet systems for huge corporations including custom made reservation systems for rooms, user management systems, shopping solutions, messaging apps etc. so i think there isn't anything related to databases and dynamic data, which cannot be achieved.

[Oscar - Xavia Digital]

Hi Teodor,

I can not teach concrete examples because my clients would not be too excited if I published them

But for example, an app that we are programming now manages users through login against Active Directory of a windows server.

This app has classic parts, using mysql, inserts in bd, updates, mails. Clasic work that we do using dreamweaver + extensions to do it.

Other parts of the application use for example login with the server windows active directory, or autocompletes of jquery whose results are returned making queries against that server. We use code made by us by hand. It's this kind of thing that I'm referring to.

Greetings and thanks again!

[osgood_]

-Michele  wrote

Another "little" problem is that the DMXzone's client-side solutions are proprietary (I mean the framework), which means that if they close, your business is over (e.g. remember InterAKT with PHAkt).

Yes, Wappler uses its own workflow, similar to vue.js or one of the other javascript frameworks so if you are dependent on it and not going to dive into how it processes the information that could be a big issue if they ever decide to put Wappler to bed.  It's a choice you must make depending o your coding experience. Muse died and left developers, if you can call people who used Muse developers, for dead, so it can and does happen and will happen again.

Its much better in my opinion to roll-your-own  based on tried, trusted workflows which have a lot of open-source support and solutions.

Initailly when you use client side scripting the page takes longer to process but is said to be quicker than server-side after that but lets get this right we are talking about huge sites such as facebook, google, linkedin of that kind of magnitude where the server is getting hit thousands of times a minute, not some small site which gets 500-1000 hits a day, in that context there is no issue to using sever-side to process information. having siad that client side is very nice as its a lot smoother for the user but there is issues as far as I know with SEO from what I've been reading......so in what context/wher you use it should be considered.

If you're using ajax for backend admin then who cares, just be wary and careful if you intend to introduce it for all front end workflow. I suggest you read about it and what others say who are unbiased and form an opinion based on that.

[pziecina]

osgood_  wrote

If you're using ajax for backend admin then who cares, just be wary and careful if you intend to introduce it for all front end workflow. I suggest you read about it and what others say who are unbiased and form an opinion based on that.

I was not going to join in this discussion, mainly because the use of mysqli and pdo cannot be used on the same page, so each type of extension is aimed at a different type of user, and/or how a site should work.

The question of using ajax or not, is more one of end user expectations and the type/part of site being used.

Most users I would argue expect a page refresh if they click on a product, but also expect a modal window if they select 'brief details/overview'.

On the back-end, (cms, app) it is becomming more common, (larger cms's/apps) for the back-end to look, feel and function more like an actual program, and not a simple, (eg wordpress) cms's back end for adding content, so ajax for much of 'what happens' is becomming more expected as a standard way of working. This of course depends on what the back-end or an application that the user must log into, required functionality and use is.

[osgood_]

pziecina  wrote

osgood_   wrote

On the back-end, (cms, app) it is becomming more common, (larger cms's/apps) for the back-end to look, feel and function more like an actual program, and not a simple, (eg wordpress) cms's back end for adding content, so ajax for much of 'what happens' is becomming more expected as a standard way of working. This of course depends on what the back-end or an application that the user must log into, required functionality and use is.

I wasnt saying who cares about the back-end, I was saying who cares If client-side processing 'does' (some say it does, others say it doesnt) have an impact on SEO.......it doens't matter in the back end.

I think here, it's more use client-side where its effective and you don't necessarily want a page-refresh. That might be more of an app style approach, within a website, where you a have a <select> menu to traverse through an image gallery to sort them into categories etc or to return the data a user has provided in a feedback from back to the browser for them to check before its finally sent for processing.

As I said the other day things are becomeing more complex and websites are becoming and acting more like app than the kind of websites we knew 10 years ago.

[pziecina]

The problem with SEO, is that Google will not tell us how they arrive at the rankings, and what they do tell us to do in theory, they often do not apply or take into consideration in practice.

An html5 site using semantic mark-up, should get a higher rating if the content is just as good as a site using divs, (but it does not always do so). SOE for a dynamic site should be the same for both ajax and page refresh, but I will concede that it may also depend on how the ajax is implemented.

If the ajax functions as per the WCAG, then the SEO should be the same. If there is no accessibility considerations built into the ajax functionality, then I have no idea what happens to the SEO, (another Google secret, (they say accessibility help in score!) so it should be a lower score).

[osgood_]

Google did upgrade its SEO to take into account client side processing  but l dont think other search engines have followed suit.......yes, there are other search engines which are used.

I also read about the implementation of ajax in conjunction with SEO but l cant find any information about how one deploys it correctly........that too would probably be open to debate, as so much of this stuff now seems to be.

101 ways to do the same thing and 101 different views and perspectives.