1. Re[4]: [GEN] Template Handler
> Thomas,
> That sounded so easy, I had to think a while to see if there was something
> wrong with it; one thing is that some "updating" templates wouldn't be new
> *files*, since individual template files are whole *categories* of
> templates, containing potentially more than one template, so I'm trying to
> make sure I can do something which will *add* any such into their
> appropriate already existing files.
> But your suggestion does make me think I'll scrap what I've been doing in
> terms of putting *both* new files of templates *and* new templates meant to
> go into existing files into the same "update" file; probably any new
> files(categories) of templates can just be distributed essentially as you
> said (I was just going to have them in the same folder as the Handler, not
> sure if I need to put them into a subfolder), and reserve the "update" file
> for templates which need to be put into existing template files.
> Thanks!
> Dan
How about having the name of the category in each file rather than
relying on the filenames? Then a category could be made up of multiple
files which are merged as they are loaded.
Thomas Parslow (PatRat) ICQ #:26359483
Rat Software
http://www.rat-software.com/
Please leave quoted text in place when replying
2. Re: Re[4]: [GEN] Template Handler
Thomas,
I might use your suggestion, though there are a few problems with it.
I already *do* have category designators in each file, but I had made them
unique, that is, one category, one file; each file has a file name *and* an
interior "category" descriptor, and all templates in that file are of that
category and all templates of that category are in that file. And the
handler *uses* them like that.
I think you are suggesting that I retain the idea that a file of templates
be all of the same category, but allow multiple files to have templates
belonging to the same category, specifically for the purpose of adding new
templates for the user?
That way, completely new categories of templates could be distributed simply
as "normal" template files (*.Etp or *.Wtp), recognized and utilized by the
handler automatically, and templates to be added to existing categories
could also just be distributed as "normal" template files, with the handler
using the internal "category" designator to put the templates into the
proper place in the internal variable and put their names into the proper
combo box for selection by the user.
That's certainly simple enough, if I've understood correctly what you were
suggesting!
I can think of these problems, though:
1. there is a possibility/likelihood of duplicate filenames with different
people submitting various template files, not sure exactly how to handle
that;
2. it ends up putting potentially lots of little files on peoples drives
instead of a smaller number of larger files. Of course, the user could
relatively easily manually combine files of identical categories into one
file, but I'd hoped to make that kind of thing unnecessary. Or I could make
the handler discern when there are multiple files of the same category, and
ask the user if they want them combined into one file, maybe.
3. and there's a kind of "general" problem of how would a user easily know
which templates are really new and which might they already have, perhaps in
a file with a different name or something; I really want to make the process
of adding (& fixing buggy templates!) *very* easy for the user.
But other than that it sounds like a good, simple idea which I should be
able to implement fairly easily (& that's a big plus too!).
I'll probably give it a try, thanks!
Dan
----- Original Message -----
From: "Thomas Parslow (PatRat)" <patrat at rat-software.com>
To: "EUforum" <EUforum at topica.com>
Sent: Wednesday, September 26, 2001 7:19 AM
Subject: Re[4]: [GEN] Template Handler
>
> > Thomas,
>
> > That sounded so easy, I had to think a while to see if there was
something
> > wrong with it; one thing is that some "updating" templates wouldn't be
new
> > *files*, since individual template files are whole *categories* of
> > templates, containing potentially more than one template, so I'm trying
to
> > make sure I can do something which will *add* any such into their
> > appropriate already existing files.
>
> > But your suggestion does make me think I'll scrap what I've been doing
in
> > terms of putting *both* new files of templates *and* new templates meant
to
> > go into existing files into the same "update" file; probably any new
> > files(categories) of templates can just be distributed essentially as
you
> > said (I was just going to have them in the same folder as the Handler,
not
> > sure if I need to put them into a subfolder), and reserve the "update"
file
> > for templates which need to be put into existing template files.
>
> > Thanks!
>
> > Dan
>
> How about having the name of the category in each file rather than
> relying on the filenames? Then a category could be made up of multiple
> files which are merged as they are loaded.
>
> Thomas Parslow (PatRat) ICQ #:26359483
> Rat Software
> http://www.rat-software.com/
> Please leave quoted text in place when replying
3. Re: Re[4]: [GEN] Template Handler
My suggestion is to have a file for each MAIN category. One for DOS code,
one for WIN code, one for LINUX code, on for GENERAL code, etc..
The purpose of the seperate files is mostly for speed, once the template
files get larger.
Maybe make that optional, allowing the user to choose the name of the file
to contain a specific category of templates.
I wouldn't even restrict it to platform categories. IMHO, it would be very
convienient to store the templates to a category file of a more appropriate
name.
For myself I would certainly have a 'sequence operations' category file for
example.
Add an export/import option to the program to create templates user
templates or add them to the main templates.
When a file is exported, a unique id is written to file.
When the file is imported, the templates it contains are added to the main
template files, and the unique id is written to a database of id's.
You can expand on that, and add more options for exporting/importing only
selected templates.
Chris
> Thomas,
>
> I might use your suggestion, though there are a few problems with it.
>
> I already *do* have category designators in each file, but I had made them
> unique, that is, one category, one file; each file has a file name *and*
an
> interior "category" descriptor, and all templates in that file are of that
> category and all templates of that category are in that file. And the
> handler *uses* them like that.
>
> I think you are suggesting that I retain the idea that a file of templates
> be all of the same category, but allow multiple files to have templates
> belonging to the same category, specifically for the purpose of adding new
> templates for the user?
>
> That way, completely new categories of templates could be distributed
simply
> as "normal" template files (*.Etp or *.Wtp), recognized and utilized by
the
> handler automatically, and templates to be added to existing categories
> could also just be distributed as "normal" template files, with the
handler
> using the internal "category" designator to put the templates into the
> proper place in the internal variable and put their names into the proper
> combo box for selection by the user.
>
> That's certainly simple enough, if I've understood correctly what you were
> suggesting!
>
> I can think of these problems, though:
> 1. there is a possibility/likelihood of duplicate filenames with different
> people submitting various template files, not sure exactly how to handle
> that;
> 2. it ends up putting potentially lots of little files on peoples drives
> instead of a smaller number of larger files. Of course, the user could
> relatively easily manually combine files of identical categories into one
> file, but I'd hoped to make that kind of thing unnecessary. Or I could
make
> the handler discern when there are multiple files of the same category,
and
> ask the user if they want them combined into one file, maybe.
> 3. and there's a kind of "general" problem of how would a user easily
know
> which templates are really new and which might they already have, perhaps
in
> a file with a different name or something; I really want to make the
process
> of adding (& fixing buggy templates!) *very* easy for the user.
>
> But other than that it sounds like a good, simple idea which I should be
> able to implement fairly easily (& that's a big plus too!).
>
> I'll probably give it a try, thanks!
>
> Dan
>
>
> ----- Original Message -----
> From: "Thomas Parslow (PatRat)" <patrat at rat-software.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Wednesday, September 26, 2001 7:19 AM
> Subject: Re[4]: [GEN] Template Handler
>
>
> > > Thomas,
> >
> > > That sounded so easy, I had to think a while to see if there was
> something
> > > wrong with it; one thing is that some "updating" templates wouldn't be
> new
> > > *files*, since individual template files are whole *categories* of
> > > templates, containing potentially more than one template, so I'm
trying
> to
> > > make sure I can do something which will *add* any such into their
> > > appropriate already existing files.
> >
> > > But your suggestion does make me think I'll scrap what I've been doing
> in
> > > terms of putting *both* new files of templates *and* new templates
meant
> to
> > > go into existing files into the same "update" file; probably any new
> > > files(categories) of templates can just be distributed essentially as
> you
> > > said (I was just going to have them in the same folder as the Handler,
> not
> > > sure if I need to put them into a subfolder), and reserve the "update"
> file
> > > for templates which need to be put into existing template files.
> >
> > > Thanks!
> >
> > > Dan
> >
> > How about having the name of the category in each file rather than
> > relying on the filenames? Then a category could be made up of multiple
> > files which are merged as they are loaded.
> >
> > Thomas Parslow (PatRat) ICQ #:26359483
> > Rat Software
> > http://www.rat-software.com/
> > Please leave quoted text in place when replying
>
>
>
4. Re: Re[4]: [GEN] Template Handler
Chris,
you wrote:
>
> My suggestion is to have a file for each MAIN category. One for DOS code,
> one for WIN code, one for LINUX code, on for GENERAL code, etc..
Ok, I think I like that idea, and will consider using it.
What I'm *currently* thinking would be like this:
Handler could be made to work with 3 basic types of template files:
1. "main" template files: tmplates.dos, .win, .lin, .eds, etc
(each file would hold multiple categories of templates, relevant to
the "platform"
indicated in the extent)
2. "small" template files, for personal use and user contributions to RDS
site,
abcd.Etp, abcd.Wtp, abcd.Ltp, abcd.Dtp(eDs database templates?);
the handler would save these, and could of course load & use them,
too.
(each file would be a separate category, either user defined or an
existing
category from original or updated distribution of templates? Or,
could use
Thomas' suggestion and allow different files to contain templates of
same
category. When user *creates* new category, all get written to same
file, but
when handler *read* files, can get templates of same category from
different
files?)
(problem exists with regard to users inadvertenly using same filename,
as well as
same template name for different templates, and different category
names for
essentially same category)
3. "update" or "new templates" files, "NewTplts.aa1" etc
(each file could contain mixture of templates in *new* categories,
and templates
in *existing* categories from original or updated distribution of
templates);
this file would be read in by user selecting "update", templates
would be put into
appropriate variable for immediate use and added to appropriate main
template
files, and after that the update file would be renamed something like
"BakTplts.aa1", so user could know in the future that they had already
updated
with it. Could also build a 'list of previous updates' into the
update selection, and
maybe an automatic check against "BakTplts.xxx" before an update
proceeds.
> The purpose of the seperate files is mostly for speed, once the template
> files get larger.
> Maybe make that optional, allowing the user to choose the name of the file
> to contain a specific category of templates.
I think my #2 would do that for a user's self-created templates?
> I wouldn't even restrict it to platform categories. IMHO, it would be very
> convienient to store the templates to a category file of a more
appropriate
> name.
#2 again? You could add as many templates as you want to a file/category of
your own creation.
> For myself I would certainly have a 'sequence operations' category file
for
> example.
YES! Well, not necesarly(?) as a *separate* file, but *certainly* as a
category! In fact, in the couple of sample templates I just sent to Robert,
'Sequence Manipulations' *is* a category :)
And one of the templates included comes from a suggestion for using &=
instead of append that you posted once, which I retrieved from my "code
samples" email folder & slightly corrected.
Any templates people can contribute for *that* category will be *greatly*
appreciated!
>
> Add an export/import option to the program to create templates user
> templates or add them to the main templates.
> When a file is exported, a unique id is written to file.
> When the file is imported, the templates it contains are added to the main
> template files, and the unique id is written to a database of id's.
>
I'm not *sure* I understand. Would this relate to a person creating a
template for their own use, and then wanting to save it in a special format
for upload for other users? If so, that would seem to separate "update" new
templates from "import" user created templates, which does seem to be a good
idea. In other words, "officially" updated templates might receive some
small "overview" (or checking for erroneous or malicious code (sigh!)), but
"imported" templates might not?
Of course, the handler already *can* save templates the user creates, to a
"small" file currently one file, one category; *adding* imported templates
to the (proposed) main template files is something I've considered, but I'm
not yet sure whether it is a good idea or not.
> You can expand on that, and add more options for exporting/importing only
> selected templates.
Yes, that would be a reasonable additional feature.
Thanks, now I got to *think* about it all!
>
> Chris
>
>
> > Thomas,
> >
> > I might use your suggestion, though there are a few problems with it.
> >
> > I already *do* have category designators in each file, but I had made
them
> > unique, that is, one category, one file; each file has a file name *and*
> an
> > interior "category" descriptor, and all templates in that file are of
that
> > category and all templates of that category are in that file. And the
> > handler *uses* them like that.
> >
> > I think you are suggesting that I retain the idea that a file of
templates
> > be all of the same category, but allow multiple files to have templates
> > belonging to the same category, specifically for the purpose of adding
new
> > templates for the user?
> >
> > That way, completely new categories of templates could be distributed
> simply
> > as "normal" template files (*.Etp or *.Wtp), recognized and utilized by
> the
> > handler automatically, and templates to be added to existing categories
> > could also just be distributed as "normal" template files, with the
> handler
> > using the internal "category" designator to put the templates into the
> > proper place in the internal variable and put their names into the
proper
> > combo box for selection by the user.
> >
> > That's certainly simple enough, if I've understood correctly what you
were
> > suggesting!
> >
> > I can think of these problems, though:
> > 1. there is a possibility/likelihood of duplicate filenames with
different
> > people submitting various template files, not sure exactly how to
handle
> > that;
> > 2. it ends up putting potentially lots of little files on peoples drives
> > instead of a smaller number of larger files. Of course, the user could
> > relatively easily manually combine files of identical categories into
one
> > file, but I'd hoped to make that kind of thing unnecessary. Or I could
> make
> > the handler discern when there are multiple files of the same category,
> and
> > ask the user if they want them combined into one file, maybe.
> > 3. and there's a kind of "general" problem of how would a user easily
> know
> > which templates are really new and which might they already have,
perhaps
> in
> > a file with a different name or something; I really want to make the
> process
> > of adding (& fixing buggy templates!) *very* easy for the user.
> >
> > But other than that it sounds like a good, simple idea which I should be
> > able to implement fairly easily (& that's a big plus too!).
> >
> > I'll probably give it a try, thanks!
> >
> > Dan
> >
> >
> > ----- Original Message -----
> > From: "Thomas Parslow (PatRat)" <patrat at rat-software.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Wednesday, September 26, 2001 7:19 AM
> > Subject: Re[4]: [GEN] Template Handler
> >
> >
> > > > Thomas,
> > >
> > > > That sounded so easy, I had to think a while to see if there was
> > something
> > > > wrong with it; one thing is that some "updating" templates wouldn't
be
> > new
> > > > *files*, since individual template files are whole *categories* of
> > > > templates, containing potentially more than one template, so I'm
> trying
> > to
> > > > make sure I can do something which will *add* any such into their
> > > > appropriate already existing files.
> > >
> > > > But your suggestion does make me think I'll scrap what I've been
doing
> > in
> > > > terms of putting *both* new files of templates *and* new templates
> meant
> > to
> > > > go into existing files into the same "update" file; probably any new
> > > > files(categories) of templates can just be distributed essentially
as
> > you
> > > > said (I was just going to have them in the same folder as the
Handler,
> > not
> > > > sure if I need to put them into a subfolder), and reserve the
"update"
> > file
> > > > for templates which need to be put into existing template files.
> > >
> > > > Thanks!
> > >
> > > > Dan
> > >
> > > How about having the name of the category in each file rather than
> > > relying on the filenames? Then a category could be made up of multiple
> > > files which are merged as they are loaded.
> > >
> > > Thomas Parslow (PatRat) ICQ #:26359483
> > > Rat Software
> > > http://www.rat-software.com/
> > > Please leave quoted text in place when replying
> >
> >
>
>
5. Re: Re[4]: [GEN] Template Handler
Dan,
2. After further consideration, I don't think it's a good idea to bother
trying to keep track of what templates have been included or not. Leave it
up to the user.
When I download something from the internet, It doesn't tell me that I have
already dl'd it, unless I try to put it in the same directory.
The problem with trying to keep track of which templates have been added
already, is that you would need to keep track of each individual code
template, due to the fact that a user would be able to choose which
templates they want included.
And then at that, two code templates may have the same title, but contain
different code, what then?
What if two different template files contain some of the same code
templates?
What if the user chooses to only import a select few code templates from a
file? How do you flag that file?
I'd also suggest setting up a web page for the templates. this removes the
burden from Rob, and allows you to keep track of the templates.
3. I was suggesting that import would replace update, as it makes more
sense, but having official updates IS a good idea :)
I don't think it's nessecary to have a seperate function for official
updates though.
I didn't notice an option for sub categories...
Just as an Example....
I want to be able to have a game development template category, with a sub
category for DOS, WIN, LNX, and GEN.
In those categories, I would have more sub categories for SPRITES, TILE MAPS
(which would have a sub categories for ISOMETRIC, HEX and RECTANGULAR tile
maps (these categories would probably contain other categories as well) ),
3D, EFFECTS, SOUND, etc..
I think you get the point.
Chris
> Chris,
>
> you wrote:
> >
> > My suggestion is to have a file for each MAIN category. One for DOS
code,
> > one for WIN code, one for LINUX code, on for GENERAL code, etc..
>
> Ok, I think I like that idea, and will consider using it.
>
> What I'm *currently* thinking would be like this:
> Handler could be made to work with 3 basic types of template files:
> 1. "main" template files: tmplates.dos, .win, .lin, .eds, etc
> (each file would hold multiple categories of templates, relevant to
> the "platform"
> indicated in the extent)
>
> 2. "small" template files, for personal use and user contributions to
RDS
> site,
> abcd.Etp, abcd.Wtp, abcd.Ltp, abcd.Dtp(eDs database templates?);
> the handler would save these, and could of course load & use them,
> too.
> (each file would be a separate category, either user defined or an
> existing
> category from original or updated distribution of templates? Or,
> could use
> Thomas' suggestion and allow different files to contain templates of
> same
> category. When user *creates* new category, all get written to same
> file, but
> when handler *read* files, can get templates of same category from
> different
> files?)
> (problem exists with regard to users inadvertenly using same
filename,
> as well as
> same template name for different templates, and different category
> names for
> essentially same category)
>
> 3. "update" or "new templates" files, "NewTplts.aa1" etc
> (each file could contain mixture of templates in *new* categories,
> and templates
> in *existing* categories from original or updated distribution of
> templates);
> this file would be read in by user selecting "update", templates
> would be put into
> appropriate variable for immediate use and added to appropriate
main
> template
> files, and after that the update file would be renamed something
like
> "BakTplts.aa1", so user could know in the future that they had
already
> updated
> with it. Could also build a 'list of previous updates' into the
> update selection, and
> maybe an automatic check against "BakTplts.xxx" before an update
> proceeds.
>
> > The purpose of the seperate files is mostly for speed, once the template
> > files get larger.
> > Maybe make that optional, allowing the user to choose the name of the
file
> > to contain a specific category of templates.
>
> I think my #2 would do that for a user's self-created templates?
>
> > I wouldn't even restrict it to platform categories. IMHO, it would be
very
> > convienient to store the templates to a category file of a more
> appropriate
> > name.
>
> #2 again? You could add as many templates as you want to a file/category
of
> your own creation.
>
> > For myself I would certainly have a 'sequence operations' category file
> for
> > example.
>
> YES! Well, not necesarly(?) as a *separate* file, but *certainly* as a
> category! In fact, in the couple of sample templates I just sent to
Robert,
> 'Sequence Manipulations' *is* a category :)
> And one of the templates included comes from a suggestion for using &=
> instead of append that you posted once, which I retrieved from my "code
> samples" email folder & slightly corrected.
> Any templates people can contribute for *that* category will be *greatly*
> appreciated!
>
> >
> > Add an export/import option to the program to create templates user
> > templates or add them to the main templates.
> > When a file is exported, a unique id is written to file.
> > When the file is imported, the templates it contains are added to the
main
> > template files, and the unique id is written to a database of id's.
> >
>
> I'm not *sure* I understand. Would this relate to a person creating a
> template for their own use, and then wanting to save it in a special
format
> for upload for other users? If so, that would seem to separate "update"
new
> templates from "import" user created templates, which does seem to be a
good
> idea. In other words, "officially" updated templates might receive some
> small "overview" (or checking for erroneous or malicious code (sigh!)),
but
> "imported" templates might not?
>
> Of course, the handler already *can* save templates the user creates, to a
> "small" file currently one file, one category; *adding* imported
templates
> to the (proposed) main template files is something I've considered, but
I'm
> not yet sure whether it is a good idea or not.
>
> > You can expand on that, and add more options for exporting/importing
only
> > selected templates.
>
> Yes, that would be a reasonable additional feature.
>
> Thanks, now I got to *think* about it all!
>
> >
> > Chris
> >
> >
> > > Thomas,
> > >
> > > I might use your suggestion, though there are a few problems with it.
> > >
> > > I already *do* have category designators in each file, but I had made
> them
> > > unique, that is, one category, one file; each file has a file name
*and*
> > an
> > > interior "category" descriptor, and all templates in that file are of
> that
> > > category and all templates of that category are in that file. And the
> > > handler *uses* them like that.
> > >
> > > I think you are suggesting that I retain the idea that a file of
> templates
> > > be all of the same category, but allow multiple files to have
templates
> > > belonging to the same category, specifically for the purpose of adding
> new
> > > templates for the user?
> > >
> > > That way, completely new categories of templates could be distributed
> > simply
> > > as "normal" template files (*.Etp or *.Wtp), recognized and utilized
by
> > the
> > > handler automatically, and templates to be added to existing
categories
> > > could also just be distributed as "normal" template files, with the
> > handler
> > > using the internal "category" designator to put the templates into the
> > > proper place in the internal variable and put their names into the
> proper
> > > combo box for selection by the user.
> > >
> > > That's certainly simple enough, if I've understood correctly what you
> were
> > > suggesting!
> > >
> > > I can think of these problems, though:
> > > 1. there is a possibility/likelihood of duplicate filenames with
> different
> > > people submitting various template files, not sure exactly how to
> handle
> > > that;
> > > 2. it ends up putting potentially lots of little files on peoples
drives
> > > instead of a smaller number of larger files. Of course, the user
could
> > > relatively easily manually combine files of identical categories into
> one
> > > file, but I'd hoped to make that kind of thing unnecessary. Or I
could
> > make
> > > the handler discern when there are multiple files of the same
category,
> > and
> > > ask the user if they want them combined into one file, maybe.
> > > 3. and there's a kind of "general" problem of how would a user easily
> > know
> > > which templates are really new and which might they already have,
> perhaps
> > in
> > > a file with a different name or something; I really want to make the
> > process
> > > of adding (& fixing buggy templates!) *very* easy for the user.
> > >
> > > But other than that it sounds like a good, simple idea which I should
be
> > > able to implement fairly easily (& that's a big plus too!).
> > >
> > > I'll probably give it a try, thanks!
> > >
> > > Dan
> > >
> > >
> > > ----- Original Message -----
> > > From: "Thomas Parslow (PatRat)" <patrat at rat-software.com>
> > > To: "EUforum" <EUforum at topica.com>
> > > Sent: Wednesday, September 26, 2001 7:19 AM
> > > Subject: Re[4]: [GEN] Template Handler
> > >
> > >
> > > > > Thomas,
> > > >
> > > > > That sounded so easy, I had to think a while to see if there was
> > > something
> > > > > wrong with it; one thing is that some "updating" templates
wouldn't
> be
> > > new
> > > > > *files*, since individual template files are whole *categories* of
> > > > > templates, containing potentially more than one template, so I'm
> > trying
> > > to
> > > > > make sure I can do something which will *add* any such into their
> > > > > appropriate already existing files.
> > > >
> > > > > But your suggestion does make me think I'll scrap what I've been
> doing
> > > in
> > > > > terms of putting *both* new files of templates *and* new templates
> > meant
> > > to
> > > > > go into existing files into the same "update" file; probably any
new
> > > > > files(categories) of templates can just be distributed essentially
> as
> > > you
> > > > > said (I was just going to have them in the same folder as the
> Handler,
> > > not
> > > > > sure if I need to put them into a subfolder), and reserve the
> "update"
> > > file
> > > > > for templates which need to be put into existing template files.
> > > >
> > > > > Thanks!
> > > >
> > > > > Dan
> > > >
> > > > How about having the name of the category in each file rather than
> > > > relying on the filenames? Then a category could be made up of
multiple
> > > > files which are merged as they are loaded.
> > > >
> > > > Thomas Parslow (PatRat) ICQ #:26359483
> > > > Rat Software
> > > > http://www.rat-software.com/
> > > > Please leave quoted text in place when replying
> > >
> > >
>
>
