bkonia
Posts: 7
|
| Posted: 10/29/2006, 7:59 AM |
|
Guys, it's almost 2007. We're in the midst of a revolution, you may have heard of...it's called Web 2.0. Don't you think it's time that CCS included AJAX functionality? Also, don't you think it's a bit ridiculous that a RAD product, which was just upgraded to a new version STILL does not generate valid XHTML? I mean, come on!
Sorry, I don't mean to trash CCS or Yes Software. CCS is a fantastic product and I've used it for years. The fact that I'm still using it, despite these glaring deficiencies is a testament to how great it is. Nevertheless, I'm becoming more and more dismayed by the fact that Yes keeps adding new features, but seemingly ignores the very foundation of any RAD tool, which is that it should generate clean, standards-compliant code. Newsflash: The standard is now XHTML, not HTML.
Another thing you guys should take note of...I noticed that version 3.1 includes support for FCKeditor. This is a nice feature, but FCKeditor is not the state-of-the-art in WYSIWYG editors. If you really want to be forward thinking, you should also include support for XStandard, which IS the state-of-the-art, due to the fact that it's built from the ground-up as a pure standards-compliant XHTML editor. XStandard has a free lite version and they encourage third party developers to integrate it into their products.
_________________
Brad S Konia |
 |
|
robertmann
Posts: 109
|
| Posted: 10/29/2006, 2:35 PM |
|
Xstandard is a Web browser plugin for Windows. Our Web applications cannot support it without asking everyone to download and install Xstandard lite on their Windows computers.
What am I missing?
Ajax support indeed would be nice if it fits CCS scope and direction but I am not sure if we should expect it. Some Ajax tools are expensive and much different in scope than CCS. Possibly CCS could provide integration with Ajax tools that we could afford?
Or provide integration with AJAX frameworks that we already use?
XHTML would be nice! Why there was only one request for it? http://forums.codecharge.com/forum.php?s_topic_name=xhtml&forum_id=22
_________________
Robert |
|
|
|
bkonia
Posts: 7
|
| Posted: 10/29/2006, 3:17 PM |
|
Quote robertmann:
Xstandard is a Web browser plugin for Windows. Our Web applications cannot support it without asking everyone to download and install Xstandard lite on their Windows computers.
What am I missing?
XStandard can be installed on-the-fly in both IE and Firefox. XStandard would typically be used for applications such as corporate intranets, CMS, etc... In these types of applications, it's critical that the users are forced to output valid XHTML, since many users would be collaborating to publish a public website. It should also be noted that these are the most common types of applications that people use CCS to develop. Therefore, the slight inconvenience of having to install the plugin is vastly outweighed by the benefit of standardized code. For other types of applications (forums, etc...), I agree the FCKeditor would be a better choice, since the average user is clueless about XHTML and you don't want to force your users to install a plugin in order to use your website.
Quote robertmann:
Ajax support indeed would be nice if it fits CCS scope and direction but I am not sure if we should expect it. Some Ajax tools are expensive and much different in scope than CCS. Possibly CCS could provide integration with Ajax tools that we could afford?
Or provide integration with AJAX frameworks that we already use?
I don't know, Robert. I hear what you're saying, but look, CCS is a RAD tool. That means its whole purpose in life is to accelerate the development of web applications. Now the question becomes, "What is a web application?" Five years ago, a web application would consist of simple HTML forms with standard HTML form controls. However, time has moved on and CCS needs to provide its users with a way to develop modern web applications, otherwise it will become irrelevant as a RAD. Think about it. When was the last time you saw a Web 2.0 site that didn't use an AJAX interface? Every new site that comes on the market today is using AJAX and if CCS doesn't support it soon, users will start to look for other options.
Quote robertmann:
Actually, if you do a forum search for "xhtml" and search ALL the forums (not just this forum), you will find numerous requests for XHTML support.
_________________
Brad S Konia |
|
|
|
peterr
Posts: 5971
|
| Posted: 10/29/2006, 4:33 PM |
|
Hi Brad,
May I ask in a friendly way where were you where everyone was discussing WYSIWYG editors and asking for FCKeditor support?  We would like to see your comments prior to implementing a new feature, rather than after.
However, I can also see that the requirement to install XStandard as a plug-in is a serious drawback and cannot be ignored. Not everyone treats this requirement as slight inconvenience, therefore other comments (and related requests) would be welcome.
And there is still room in CCS to include support for new components.
Ajax support is a valid request.
Just please don't think that we're just napping all the time and haven't heard of Ajax
Let's also not assume that CCS must do everything related to the Web. Not long ago CCS didn't support Web reporting and didn't have to, either. And if Web reporting features were not included in CCS then people would find other tools for it - fine. Currently many CCS users also use Ajax frameworks with CCS. Others may be using other tools, or just multiple tools in their work. While I vote for Ajax support in CCS too.
XHTML is also a good point and becoming high priority.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
bkonia
Posts: 7
|
| Posted: 10/29/2006, 4:59 PM |
|
Quote peterr:
May I ask in a friendly way where were you where everyone was discussing WYSIWYG editors and asking for FCKeditor support? We would like to see your comments prior to implementing a new feature, rather than after.
As I mentioned in my second post, FCKeditor and XStandard are not mutually exclusive. While they are both WYSIWYG editors, they serve different purposes and it would be great to have both of them included in CCS.
Quote peterr:
Ajax support is a valid request.
Just please don't think that we're just napping all the time and haven't heard of Ajax
I don't think you're napping. I know that you're adding new features all the time. My point was that by definition, a RAD should faciltate rapid application development. Furthermore, in the world of Web 2.0, the definition of a web application is now standardizing on AJAX, in much the same way that Web 1.0 standardized on HTML and Javascript. So if we define an "application" as being AJAX-based, we expect our RAD to be able to create AJAX based applications. If you have to use additional third party tools to accomplish this, then the development process becomes much more cumbersome and our RAD is no longer a RAD. It's a SAD 
Again, I know you guys are doing good work. It's just that some of the features that have been added recently seem like they're much less important than AJAX in terms of the fundamental mission of CCS.
_________________
Brad S Konia |
|
|
|
Edd
Posts: 547
|
| Posted: 10/29/2006, 11:20 PM |
|
Brad,
I have used Ajax components with CCS for 2 years now and I am still getting MAJOR issues (expecially with IE and IIS).
AJAX IS NOT A MATURE TECHNOLOGY - in other words you use it where you know your audience (example I still have people using IE4 and homegrown Linux browsers hitting my site).
I absolutely love Ajax (it revolutionises the way you build web pages) but the majority of CCS users are at the novice stage and would be floored if the Ajax additions to CCS were not as simple as dirt.
If CCS does do Ajax (and they will) - I hope it is an "add on" with a strategic partner. This way we get the best of both worlds and it would be a next toolset upgrade, from Personal then Professional then Enterprise. This then would separate the professionals from the newbies.
My two cents worth of opinion.
Edd
_________________
Accepting and instigating change are life's challenges.
http://www.syntech.com.au |
|
|
|
bkonia
Posts: 7
|
| Posted: 10/29/2006, 11:41 PM |
|
Edd,
I respect your opinion. If you've worked with AJAX for two years, then you have more experience with it than I do. Nevertheless, I get the impression that the "major issues" you're referring to have to do with the inability of older browsers to render AJAX pages. I'm curious to know why you wouldn't just lookup the user agent and redirect those browsers to a plain HTML version of your site?
You state that AJAX is not mature, yet companies like Google use it extensively. For example, the entire GMail UI is AJAX-based. Of course they offer a standard HTML version of GMail as well and they automatically redirect users to that version based on the user agent. My feeling is that if it's good enough for Google, it's good enough for pretty much anyone.
Regarding the issue of partnering with another company...this may be a reasonable short-term solution, but I think in the long run, Yes will have to develop their own AJAX components in order to remain competitive. The way I see it, the value proposition of a RAD is a function of its ability to streamline application development. If the RAD ends up outsourcing much of its capabilities to a third party solution, users may begin to wonder why they don't just develop the whole application in the AJAX toolkit. Yes would also run the risk that the company they partner with starts adding more CCS-like features to their product, essentially eliminating the need for AJAX developers to use CCS at all.
_________________
Brad S Konia |
|
|
|
Ozum
Posts: 57
|
| Posted: 10/30/2006, 5:29 AM |
|
For AJAX and JS based functions Prototype library may be a good choice to integrate with CCS. (http://wiki.script.aculo.us/scriptaculous/show/Prototype)
|
|
|
|
bkonia
Posts: 7
|
| Posted: 10/30/2006, 9:12 AM |
|
Edd mentioned that the AJAX implementation in CCS needs to be "simple as dirt" and I wholly concur. Just to add some food for thought, here's my vision for how I'd like to see AJAX implemented within CCS:
* I would like to have a new property called "Use AJAX" added to each of the recordset components (Record, Editable Grid, etc...). This would be a simple Yes/No mechanism.
* If the developer enables AJAX for a given component, this would automatically disable the "Return Page" property, since AJAX requires that the form submits to itself, rather than to another page.
* When a user clicks on the form submit button, CCS would check to see if the browser supports AJAX. If so, then it would be submitted via AJAX and the page would be refreshed without a reload. If not, it would be submitted normally.
The interesting thing is that CCS already has most of the prerequisites for AJAX in place. For instance, it has the capability to use a single page for search, record, and detail forms, hiding/showing each of the forms dynamically. The recent addition of the Panel component takes this a step further. The only thing that's missing is the actual AJAX submission mechanism, which is really almost trivial to implement.
I would suggest taking a look at AJForm, http://ajform.sourceforge.net/ . This is an extremely simple and small AJAX API available under the BSD license. It literally took me about fifteen minutes to get up and running with this API. The nice thing about AJForm is that it's strictly a form submission API. It does exactly what it's supposed to and nothing more. Thus, it would be ideal for integrating into CCS, since as I mentioned above, CCS already has all the bells and whistles...it's just missing the AJAX form submission mechanism.
_________________
Brad S Konia |
|
|
|
RonB
Posts: 228
|
| Posted: 10/30/2006, 10:31 AM |
|
Quote :the nice thing about AJForm is that it's strictly a form submission API. It does exactly what it's supposed to and nothing more. Thus, it would be ideal for integrating into CCS, since as I mentioned above, CCS already has all the bells and whistles...it's just missing the AJAX form submission mechanism
I think that's not exactly the whole picture. You mentioned yourself that ccs offers many grids on one page. Now suppose the form I just submitted changes something in the recordset I use for a grid elsewhere on the page..... that grid needs to reflect the changes in the recordset after submit. Wich means that if you do not want to reload the page you'd need an ajax mechanism to fetch the recordset just altered and proces the grid using that recordset ....all without reloading the page.
I think it's just a little bit more complicated then just submitting a form using ajax.
Ron
|
|
|
|
bkonia
Posts: 7
|
| Posted: 10/30/2006, 10:50 AM |
|
The way AJForm works is it intercepts a normal form submit and passes all the form data to a specified PHP script, which can actually be on the same page. This script then does whatever processing needs to be done on the data and passes it back to the original page via a Javascript function, without reloading the page. Therefore, the only difference between an AJAX submission and a standard submission is that the data is passed back via Javascript and the page doesn't reload.
Once the data is returned to the Javascript function, it's up to the software developer to decide what he wants to do with this data. In this case, Yes Software would have CCS do the recordset processing in the target PHP script and the result of that processing would be passed back to the Javascript function. Then, they would have to create some additional Javascript functions to dynamically update the various page elements that have changed. Thus, the only significant difference between this AJAX implementation and a standard form submit is that they would have to use Javascript to update the page elements. The backend recordset processing would be handled exactly the same way as it is now.
_________________
Brad S Konia |
|
|
|
Jan K. van Dalen
|
| Posted: 10/30/2006, 12:07 PM |
|
How about a menu editor :)
"bkonia" <bkonia@forum.codecharge> wrote in message
news:224544cff1e9e6d@news.codecharge.com...
> Guys, it's almost 2007. We're in the midst of a revolution, you may have
> heard
> of...it's called Web 2.0. Don't you think it's time that CCS included AJAX
> functionality? Also, don't you think it's a bit ridiculous that a RAD
> product,
> which was just upgraded to a new version STILL does not generate valid
> XHTML? I
> mean, come on!
>
> Sorry, I don't mean to trash CCS or Yes Software. CCS is a fantastic
> product
> and I've used it for years. The fact that I'm still using it, despite
> these
> glaring deficiencies is a testament to how great it is. Nevertheless, I'm
> becoming more and more dismayed by the fact that Yes keeps adding new
> features,
> but seemingly ignores the very foundation of any RAD tool, which is that
> it
> should generate clean, standards-compliant code. Newsflash: The standard
> is now
> XHTML, not HTML.
>
> Another thing you guys should take note of...I noticed that version 3.1
> includes support for FCKeditor. This is a nice feature, but FCKeditor is
> not
> the state-of-the-art in WYSIWYG editors. If you really want to be forward
> thinking, you should also include support for XStandard, which IS the
> state-of-the-art, due to the fact that it's built from the ground-up as a
> pure
> standards-compliant XHTML editor. XStandard has a free lite version and
> they
> encourage third party developers to integrate it into their products.
>
> _________________
> Brad S Konia
> ---------------------------------------
> Sent from YesSoftware forum
> http://forums.codecharge.com/
>
|
|
|
|
RonB
Posts: 228
|
| Posted: 10/30/2006, 11:03 PM |
|
Quote :Thus, the only significant difference between this AJAX implementation and a standard form submit is that they would have to use Javascript to update the page elements. The backend recordset processing would be handled exactly the same way as it is now.
That's doing quite a bit more then just adding an ajax component..That's what I said.
Ron
|
|
|
|
|
 |
|
|
|
