DaveRexel
Posts: 50
|
| Posted: 04/26/2004, 1:31 PM |
|
::
Yes... Textbook example of successfull transition from shareware roots to preferred enterprise-wide development IDE.
Yes, Code Charge Studio is good and cross-platform, openly extendable as the code is generated before our very eyes. However, what is frustrating as an intermediate Code Charge Studio user is the lack of easy to use information on how to extend this excellent IDE to reproduce our specialised objects (Actions, IDE controls, pages or entire sites).
What??? say what!!! Dave you're over the top as usual.
But, Yes.... Once we've tweaked a basic site design and logic we'd like a quick way as businessmen to sell the same solution to several customers and be able to redesign and update these installations from a core implementation. I will not elaborate on the programs current inherent weaknesses regarding dynamic skinning or multi-language here as this analysis is about the lack of intermediate information on the APIs.
At a glance any major player has well documented APIs so our senior programmers can serve up in-house Dreamweaver, Photoshop, Maya or Renderman scripts that will initialise our specialised frameworks and we can use the time saved to adopt the customers requirements to a greater degree.
So what of Code Charge Studio?
Brilliant and intrepid Code Charge Studio users such as Sixto Luis Santos and Bill Noble have bravely probed the depths of the as yet undocumented CCS API and published excellent proof of concept examples. While learning much from the published code provided by these generous developers we still lack an official SDK to hand to our senior programmers and thus this Code Charge Studio is not acccepted by the very talented coders in our organisation.
Yes... the entire Code Charge Studio user-base would benefit immensely from the release of API documentation and a plug-in development SDK. All the major players have realised considerable advancement through the work of 3rd parties and Code Charge Studio would not be an exception.
As a staunch supporter of Code Charge Studio since its beginning, this is an open appeal to the Code Charge Studio producers : "We want to make and sell them bells and whistles"... please, your APIs need to be open, and published preferrably as an SDK.
(this was posted on the newsgroup on the 24th of April 2004 at 2:29 am but did not replicate to the forum so I guess the two way sync is not really working)
_________________
/Dave
RexDesign CodeCharge Studio Tutorials
http://rexdesign.com/ccs/ |
 |
|
Eric Bruno
|
| Posted: 04/27/2004, 1:26 AM |
|
In the same context a HOWTO or wizard to allow
creation of user developed "Solutions"/Project Templates
like the projects provided in new project dialog under
the Solutions tab would be big help.
Eric Bruno
|
|
|
|
RonB
Posts: 228
|
| Posted: 06/12/2004, 10:32 AM |
|
I aggree with Dave. If things like actions could be user defined I think there would be a great pool of actions available very soon. I know I have wished I could turn often used code into an action. It would save time and I'm very interested in creating a library of actions wich could be used in any project.
If an SDK would allow others to develop wizzards that would be a big boost to codecharge and would definetively atract more developers.
Up untill now I can understand why it was indesirable to release an sdk. There were many major changes in a relaviely short period of time and we all have seen that these changes broke some of the fore mentioned user created wizzards.
Now that it seems we have left the beta stages behind I think it would be wise to let the user community get creative. There's nothing that will keep interest in a product going like an active user community and active development of add-on's.
|
|
|
|
peterr
Posts: 5971
|
| Posted: 06/13/2004, 1:11 PM |
|
Hi,
I just like to point that the Actions are the easiest to create and you could try experimenting, by for example taking the Print Text action (C:\Program Files\CodeChargeStudio\Components\Actions\Server\General\Print Text.xml) and modifying it.
The 'secret' here is that we ourselves used the Notepad and XML+XSL to create those actions. Therefore the SDK that we use is XML & XSL. This is what we had to learn ourselves to create Actions and there is basically nothing else involved. If you want the same SDK that we use then here it is: http://www.google.com/search?q=xml+xsl+tutorial 
We think that this may be the biggest area of opportunity for our community - to create and share custom Actions already. We could help some of you get started, resolve issues and answer questions. Some CCS users may even want to create articles on how they dealt with it, thus getting involved and helping us build the CCS user community. Then later we could move onto more difficult tasks like generating custom code, which also is done via XML and XSL.
How does this sound?
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
RonB
Posts: 228
|
| Posted: 06/17/2004, 10:07 AM |
|
It's a good start. Now how about providing a gui in CCS to handle all that difficult stuff?
|
|
|
|
peterr
Posts: 5971
|
| Posted: 06/17/2004, 1:35 PM |
|
I think that we're concerned that if no one is doing this without a GUI then we simply don't know if anyone will do this when having a GUI. It could be similar to selling an electric screwdriver to someone who doesn't use a regular screwdriver.
Yes, we could and probably will do this, but the priority will be very low until we see some genuine interest and users actually create own actions. Or if we see some large number of requests for such GUI then we could consider it as well. This would be a product like any software and creating it requires some visible demand.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
darren166
Posts: 24
|
| Posted: 06/17/2004, 11:50 PM |
|
I for one would be very interested in this and would want to create actions and / or builders. I've been using CC and then CCS for more than 2 years now and have just completed a huge project using CCS as the sole interface. It is a fantastic time saver and has the potential to be an even greater one.
I would be perfectly willing to pay for new extensions so there is money to be made.
Even a few step by step examples would be a good start.
Darren.
_________________
---
a. w. d. - c o n s u l t i n g
Midnight Oil Consumers. |
|
|
|
RonB
Posts: 228
|
| Posted: 08/10/2004, 12:44 AM |
|
Quote :I think that we're concerned that if no one is doing this without a GUI then we simply don't know if anyone will do this when having a GUI. It could be similar to selling an electric screwdriver to someone who doesn't use a regular screwdriver.
Well I think a lot of people that wouldn't dream of programming in any language when all you have is a text editor are using coddechatge studio right now. For me it's the texteditor that is putting me off. Give me a gui and I'll be working fast. I gues I'm from the cut and paste generation, wich is why I like php and codecharge studio a lot
|
|
|
|
Ozum
Posts: 57
|
| Posted: 08/11/2004, 1:06 AM |
|
Although not a big company, I am the only one using CCS in my company. After surfing Dave's web page (Thanks Dave) I coded 6 or 7 custom actions in Perl such as one updating checkboxes in a record in another table, fetching next value from postgresql or resize an image and add watermark etc. All my actions use CodeCharge GUI.
However there are two important problems:
1. I could not be sure if my custom actions work in the next project, since I do not have detailed descriptions of what CCS support and what features it have via XML&XSL.
For example in my last project one of my custom actions stop functioning. After an hour I find that, I used in project settings 'Library Prefix' feature and I didn't used in my custom action XML code that puts this prefix in PERL, because I didn't know that CCS has such requirements. I had to examine Lookup action to understand what the problem is etc etc.
The average coders in my company can not handle this kind of problems. Perl, trial&error CCS, examine undocumented XML code and then write an action than again loopback.
2. When I need to change a major important point in the way CCS produce code, i crash into 'ccl' files.
For customization and normal use CCS heavily needs 2 things to solve the problems I mentioned. First, a full detailed, quality documentation of product and its features, and second a standard API and again the full detailed documentation of that API.
|
|
|
|
peterr
Posts: 5971
|
| Posted: 08/11/2004, 2:00 PM |
|
Ron,
Thanks. I get your point.
Let me try to explain this way: in our opinion the use of an SDK requires higher level skills, and even if we released an SDK we may prequalify certain users and provide it only to those who can prove that they can indeed create own Wizards, or utilities. Actually prequalifying users, or selling an SDK are couple possible approaches.
For most other users an SDK could be nice to look at, but it is of no use to 90% of people.
A visual way of creating components (visual SDK tools) could increase that number to let's say 30% of people who could use it, thus the idea is good. However:
a) this is still not as high priority as creating standard CCS features & components that everyone can use
b) a visual SDK would need to be paired with non-visual SDK (API documentation). Thus we need to get through this step first. And we're working on couple SDKs (API documents) now.
Ozum,
Thanks for your comments as well.
Since you were able to create own XML/XSL actions then this looks like great start. I'm not familiar with the issue you descibed, however I understand that whatever you are able to at least figure out and implement, should not stop working later. And I believe that we're not making almost any changes related to Actions, therefore I hope that your issue was just one exception.
In any case, we're currently working on the following API documents:
- Wizards
- CCS IDE (mostly to be accessed from Wizards)
The remaining SDK/document would be the one for the component/code generation, which includes Toolbox components and Actions. However, I must say that we do not feel ready to work on such SDK because CCS is still undergoing major expansions and changes that could render any custom components unsuable in the subsequent product versions. This is probably similar to what you have already experienced with the Actions, although I suspect that Actions will not be impacted too much.
However, the main code generation patterns (ccl) are encrypted and will remain encrypted until we can finish several additional features, and then properly organize all components so that they can be extended or added independently of each other. This is scheduled as a major effort for us after CCS 3.0 is completed, especially that CCS 3.0 itself will include a large number of changes to the generated code.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
|
 |
|
|
|
