This would save immense amounts of time.

Short of creating a base framework on which an application would be built this is an excellent suggestion.

Great idea, I wonder if that would come before or after the class editor?

Like a "code snippet" library maintained in the editor (Designer), not necessarily in an nsf. It would need to be user-definable. Even better, it would be sharable, too.

This is a great idea. As a little shameless plug, I can tell you that many developers have emailed me that this use the Paste Information tool for doing exactly this. They create documents with code snippets, and then can add in the code with the click of a button.
{ Link }

Could not agree more.

Great idea, and Alan's workaround of having a "pastable repository" should probably be adopted as core functionality too.

I think the easiest way to implement this is probably to have a "default" agent for when you create new agents, the same way you have for views. That way you can designate an agent that has all the core bits you like, and calls to "New Agent" will give you a dialog where you can either accept the default or pick another agent to base the new one on - then "customize" it.

The default library is great, but why would you ever need anything else? Just declare those standard variables in the library, and set them on the Initialize. Then "predefine functions" becomes built right in.

If you really need something more sophisticated than that, may I suggest good ol' copy/paste? Not copy the source code, but write the agent template and the copy & paste that.

If you're truly doing something like use "myStandardUtilityLibrary" AND you're also doing the rest those declarations, the blindingly obvious solution (to me) is to put the declarations into the script library. I must be missing something since so many people seem think it's a god idea.

Since so many people are promoting this can anyone explain why a script library isn't good enough?

libraries are global, first of all; and globals are bad for things like this. Libraries are also tied to databases.

The idea here is to just define the starting point of any agent I care to write. I find that 90% of the time I start my agents with the dozen or so lines.

"ideas" in this context of "ideaJam" don't have to be huge. Some of the biggest and most obvious are unlikely to get done. Example: "Get rid of the 32k limits" or "better multitasking" -- to which my only reply could be "Duh? But are you up to writing that?" What I'm talking about here is very simple, would be a big help to my day to day work, and could actually be accomplished.

"Since so many people are promoting this can anyone explain why a script library isn't good enough?"

Easy. There's no cost to promoting an idea.

Andrew's probably right that this is low-hanging fruit. It might not even be necessary for IBM to be the one to implement this in a Designer-in-Eclipse world.

However, I would also have thought that someone like Andrew would just write himself a toolbar item that would copy his preferred template agent from some static db into the current one.

Why on earth should "someone like Andrew" have to go to the trouble of creating tools like that?

I have voted demote because..

I am seeing both sides of the argument on this one, but I think for flexibility and maintainability a script library is the best way to go.

Imagine if you had a template in the way you describe Andrew and you have implemented it in 100 libraries and you want to add just one more feature too it... thats a lot of coding changes.

If you use a script library and have it inheriting from a single location, then, as you want to add features to the "base code template", you can just update the script library and then refresh the changes around using the design task or manually.

Also, when there is a development team of more than one, you will start to have issues with consistency, i.e. how do you ensure that all developers are using a standard?

At least with a script library there is control over the original and if your using a version control tool, you can ensure that changes are not made to inherited libraries, only the original.

Sorry to put a downer on your idea Andrew, but the more I think about it the more issues come to mind, so unless your a single developer working on your own in isolation and have complete control over your environment, i think the implementation of this idea would cause more problems that it could possibly solve.

James, thanks for the explanation. The difference between a script library and a code template is exactly to resolve the issues you describe. A script library is a working set of production code you can change, that impacts all the apps which use it and is shared by developers across a database or set of databases.

A code template is almost the opposite. It's a place to start from, and nothing more. Its a running start that saves you setting up your personal favorite "framework" for your code. Most of us start 90% of our agent code with the same 10 or so lines.

@15. Great explanation.I definitely have reusable code that is not ever going to make it into a script library or even make a complete sub or function. Yet it keeps coming up.
It is almost like having a clipboard with the ability to hold many distinct chunks of text. There are products like that out there and I have seen them used to simulate such a library. Some of those tools come with a database where you can save all your clips and have them persisted. It's just a great tool for coders.

We use a standaard template for new database (or applications in R8) with some standaard ls code in it. We also use "Quick elementer" from OpenNTF.org { Link }

I've been using a cliptray for code templates for years now (I think it shipped with w2k's resource kit).
Saves me the time of typing out the basic framework for a function/sub (things like error handling etc.).

I for one would welcome a feature to hold stuff like that (especially if you can share the repository with the rest of the developers in a team, so everybody can at least start off from the same base)

Maybe it would be an idea to implement this via naming conventions, e.g. if an agent named $$Template$$ exists, the designer should copy all settings/code into the new agent, when created (maybe with confirmation dialog). The same would be possible with forms, views etc.