More efficient CSS

An area I hope will be improved in forthcoming products is better CSS implementation; currently the way styles are applied is extremely clumsy - in DataAssist for example. If CSS Form Builder is to be integrated witih DataAssist, things could get a lot worse. I tried Form Builder when it was released; when a two field login form created 1000 lines of CSS code, I knew this would not be a useful product as far as I was concerned. However DataAssist is useful, and hopefully will be better in the next release, particularly if it gets closer to ADDT.

For example:
Looking at the HTML taken from a dynamically-generated results page (created initially using DataAssist), there are 332 occurences of:
class="WADAResultsTableCell"
Obviously the number will vary according to the number of columns and rows, but the point is there no need for a single occurence. The same goes for class="WADAResultsTableHeader" etc..

Adding ".WADAResultsTable td" in the style sheet and removing the redundant class="WADAResultsTableHeader" would of course solve the problem.

Is there any reason for this approach (which is used throughout your CSS generation as far as I know)? Tidying up the CSS for this single page shaved 10k of the filesize. If many users page through many pages this becomes significant as far as loading times/bandiwidth is concerned, and it seems to be totally unnecessary. It also makes the pages very cluttered and difficult to work with.

I hope this can be considered in future updates. Perhaps there is some benefit to this approach (perhaps Netscape browsers work better with this type of CSS) but I find it frustrating and amateurish, and time-consuming to fix.

I understand that requests have been made for options to exclude CSS from code generation. This is a good idea but it would better if choosing styled HTML was a usable option (particularly if the styles can be defined).

Tom Dupre

As long as this principle of Form Builder maintains of a editor that needs tons of DIVs your better of using Dream Weaver's insert form elements. It works faster without any errors and needs a little simple CSS for styling. When Form Builder would be a extension that is inserting a complete "Basic" form and producing clear and good explained styles/rules it would only use 5% of the code it needs now, be almost error free and 5 times faster to work with. The problem is that a lot of people don't really learn Dream Weaver in detail (I'm not talking about you, but in general!) . I did, so as soon as I tried Form Builder and noticed all the bugs and tons of code I went back to normal coding. You learn the principles of inserting forms with Dream Weaver in hours it's really very simple and much faster then Form Builder.
Maybe the new update will be different, but I doubt that this principle is changed for the better! Good Luck

I believe a leaner version is on the cards. In the meantime, if people do want a simple form builder that is quick and easy (and free) they should give This One a go. Much reduced weight. Only a few designs to choose from, but of course you can always play with the css afterwards (if you want).

You will still need CSSFormBuilder or some other software to provide server-side validation, though.

Thanks for your comments. I may not have been very clear in my post. I'm not really interested in Form Builder and certainly wouldn't use it. However the reason I mention it is that it seems it's going to be integrated with DataAssist (or perhaps the new framework too) which could diminish DataAssist's usefulness.

I appreciate that Form Builder may be helpful and produce attractive results for people who don't know CSS or are not concerned about the code it produces. However I would have thought DataAssist is also useful to people who do care about the code (and could possibly write it themselves) and therefore might mind about the poor and inefficient CSS that is automatically generated by DataAssist - as far as I can see, quite unneccessarily.

I would have thought the CSS produced by DataAssist - eg assigning a class to every table cell - is not only inefficient and difficult to work with, but probably more difficult to generate too. Only very little CSS is required on the page - a tiny fraction of what is generated. I expect this approach may have been implemented by someone who was more of a designer, perhaps not so familiar with CSS (though I have no doubt there are employees at Webassist who are experts in all required areas). I don't think the code is the inevitable result of automated code generation.

I hope WA will consider this aspect in the new version of DataAssist. Failing this (or in addition to this) an option to exclude CSS altogether would be very welcome.

Originally Said By: tom113673

  Thanks for your comments. I may not have been very clear in my post. I'm not really interested in Form Builder and certainly wouldn't use it. However the reason I mention it is that it seems it's going to be integrated with DataAssist (or perhaps the new framework too) which could diminish DataAssist's usefulness.

I appreciate that Form Builder may be helpful and produce attractive results for people who don't know CSS or are not concerned about the code it produces. However I would have thought DataAssist is also useful to people who do care about the code (and could possibly write it themselves) and therefore might mind about the poor and inefficient CSS that is automatically generated by DataAssist - as far as I can see, quite unneccessarily.

I would have thought the CSS produced by DataAssist - eg assigning a class to every table cell - is not only inefficient and difficult to work with, but probably more difficult to generate too. Only very little CSS is required on the page - a tiny fraction of what is generated. I expect this approach may have been implemented by someone who was more of a designer, perhaps not so familiar with CSS (though I have no doubt there are employees at Webassist who are experts in all required areas). I don't think the code is the inevitable result of automated code generation.

I hope WA will consider this aspect in the new version of DataAssist. Failing this (or in addition to this) an option to exclude CSS altogether would be very welcome.  

You talk a lot about something you are not interested in! This is a open discussion forum and I'm just giving my opinion about Forum Builder, because YOU where mentioning it to start with. I also wrote about the enormous amount of unnecessary code it is producing exactly the same thing you are talking about. No one is suggesting that you are using it or are going to use it. Maybe you have to read the reactions to your post better! Before you write something like this!!!!!!!!!!!
NEILO thanks for the wonderful tip! This extension can be very handy, downloading it now.

I still don't think you understand my post. I don't care about Form Builder because I don't use it (because of the huge amount of code it produces etc.).

My point is, this might become relevant *if Form Builder is integrated into DataAssist* (otherwise not important to me at all).

No one has commented about the superfluous CSS produced *by DataAssist* (remember I don't care about Form Builder - I really don't). Perhaps it's not a problem for other people. Is it an issue for you? I would be interested in your opinion. I would also be interested of course in a comment from WA about this apparently unnecessary code which I suspect is some legacy oversight which hopefully won't be perpetuated in future products.

I appreciate your comments but I really don't want to discuss Form Builder unless it relates to this thread.

>thanks for the wonderful tip! This extension can be very handy, downloading it now<
I forget to acknowledge this - thanks. I downloaded it when it was released. However it has nothing to do with my post. I didn't mention I was interested in a form builder (I'm not). DataAssist is not a form builder (I realise it includes form generation) - my post was about DataAssist.

Again, my apologies for failing to make things clear. I hope the point of my post is clear now.

Tom Dupre

I've just realised that the comment about the wonderful tip was a genuine comment. I assumed my failing to acknowledge the tip was the cause of the poster being so cross but clearly it was not. Now I have no idea what tone397472 is so upset about. Misunderstanding all round. Perhaps I should start a new thread.

Hi Tom,

Apologies for not addressing your post directly, - I latched on to Tone's post about FormBuilder, as I have always had a bee in my bonnet about CSSFormBuilder being WebAssist's weakest link.

I can find nothing to disagree with in your post regarding the (formatting) code generated by DataAssist. I would go a little further in saying that the bloated code - with its maze of nested tags and classes - makes the page code a barrier, rather than an aid, to understanding the workings of the page and fitting the output to your site design. I don't see the need for it, but then I am fairly comfortable with CSS, where some may not be. Each implementation involves quite a bit of time stripping out the excess formatting and reapplying ones own preferred rules and cleaner design.

I would also like a version of DataAssist in which you can use the UI to edit the recordsets etc without it adding duplicate code and breaking the page, but I'm not sure if this is a problem with DataAssist or whether it is inherent in CS3/CS4.

I wouldn't use CSSFormBuilder (to build forms). The bloated code generated by the simplest of forms is massively disproportionate to its usefulness, something that was apparent from first use. As tone397472 says (above) it is so much simpler and quicker to add the required fields using Dreamweaver's Insert > Form menu, and applying one's own, more appropriate, styles.

I don't agree that CSSFB can produce attractive results - at least not without substantial deconstruction and re-styling afterwards, which totally defeats the point of using it. At the moment it would almost be easier to build a site around a CSSFB form than build a form to fit your site.

I would point out though, that WebAssist has acknowledged the degree of dissatisfaction that has been expressed (with CSS FormBuilder), and has indicated that a future release would be a leaner, cleaner version. I suggested here a few months ago that the CSSFB GUI should have a checkbox to tick to select 'no CSS/formatting', and I also submitted an example for a no-frills simple form option with minimal (but clean) css. I would like to see a similar 'no (or minimal) styling' checkbox in Data Assist, Security Assist etc. too.

Finally, the idea behind (and the potential of) CSSFormBuilder is really good. The process 'flow' i.e. - add an element, style the element, validate the element (with multiple options along the way) and saving as presets - all within a user-friendly UI - can make this an incredibly useful tool, as long as you don't have to spend frustrated hours afterwards making it look good or stripping out the excess. And once WebAssist have incorporated the facility to dynamically assign the elements to corresponding database fields as part of the 'flow', this will be a very complete solution indeed, and will remove the need to shop around for tools to fill the gaps and meet your needs. I would certainly expect to use it.

Originally Said By: tom113673

  A If CSS Form Builder is to be integrated witih DataAssist, things could get a lot worse. I tried Form Builder when it was released; when a two field login form created 1000 lines of CSS code, I knew this would not be a useful product as far as I was concerned. However DataAssist is useful, and hopefully will be better in the next release, particularly if it gets closer to ADDT.
Tom Dupre  

"I'm not interested" in Form Builder to. I did try it a couple of times, but like I said before it is unstable and producing enormous amounts of unnecessary code. Of course I understand what you are saying, but writing "I'm not interested in" or "I don't care" sounds like the discussion can only develop in one way "YOUR WAY" and just doesn't sound nice.
The reason I wrote my part about Form Builder is because I support your opinion about it. Nothing more nothing less.
I think the Web Assist developers will be smart enough when they design a real "DYNAMIC SUITE" to make modules in it like Form Builder and Data Assist which can be individually switched on and of. So I hope that solves the problem about Form Builder and Data Assist. Except for the useless code in Data Assist, but that can be better answered by a the developer of the extension.
I have complained about unnecessary code as well, but the reaction was that that extra code was necessary?! I think there will be more modules in this "Dynamic Suite" like Universal E-mail etc.
I also gave a alternative for the way Form Builder would be handy: "Producing basic forms and clear rules/styles to fine tune with CSS, when integrated with Web Assist . And only use the editor for basic forms no styling.

What i feel when using form builder is make my development time longer, since the UI not respond quick.. it seem like lagging and make user experience very bad.

i agree about the generated code.. it just too much ! but so far Webassist listen to their user.. that's why i still could hope better form builder extension in the future..

PS: do you fill the same way as well regarding slow respond when tweak CSS form in form builder ?