Hi there,

We have a fairly large Frontier database running on OSX. We back up the disk via
Apple's Time Machine, which gives us hourly snapshots of the disk.

Recently, I've noticed that the Time Machine backups for the Frontier databases
are out of date. They're old.

After looking into it a bit more, I think Time Machine is not the cause.

It looks like the original files are not being saved to disk until Frontier
quits. If pick "Save Database..." in Frontier, then Frontier says 'Saving
database", yet the timestamp and filesize of the file does not change. These
change only when quitting Frontier.

Is there a setting somewhere that affects this behavior? I am fairly confident
that Frontier used to save 'properly.' That is, the DB saved periodically ask
changes were made, and as a result, the timestamp of the .root file was updated,
etc.

Thanks-
Bill

I am trying to view a Tool website in Frontier, but I am getting an
error message.

Here is my test URL:  http://127.0.0.1:5335/MyTestTool

The error message I get is "Sorry! There was an error: Can't process
the request because there is not object named "mytesttool. The error
was detected by Frontier 10.1a10 in mainResponder.respond."

Per the Frontier Tools page (http://frontier.userland.com/tools), I
also tried this form:

http://127.0.0.1:5335/MyTestTool/index.wsf

I got the same error message as before.

I am using Frontier 10.1a10 on a Power Mac G4, OS X 10.4.10.

Thanks in advance for any advice....

Andy Sylvester

with system.verbs.apps.eims
x = {username:"richard.green", domain:"test.com",
fullname:"Richard Green", password: "abc123", loginEnabled:
true, accountEnabled: true}
newUser(x)

On 9/26/2009, Steve Hooker said:

>I'm trying to add a new user to EIMS on Mac Classic. But, I
>cannot get the string of parameters correct. I keep getting an
>error "Encountered an unexpected data type."
>
>Below is the script, and the three attempts I have had at
>getting the formatting correct.
>
>If someone can help, I'd be eternally thankful.

Steve,

I'm sorry I didn't read your email earlier.

Conversant had (well, has, though it hasn't been used in almost
a decade) full support for EIMS, so I have scripts that do
exactly what you're trying to do.

The 'x' parameter needs to be a record, but none of your samples
look right to me (I guess you knew that). Try something like this:

with system.verbs.apps.eims
      x = {username:"richard.green", domain:"test.com",
fullname:"Richard Green", password: "abc123", loginEnabled:
true, accountEnabled: true}
      newUser(x)


(Obviously, watch out for line wrap there.)

Seth

 

Ugh, aete calls, now there's a headache long forgotten...

Can you try using your params from an applescript? To make sure the error
isn't in the EIMS call?

I also recall EIMS having the ability to accept user@domain for such calls,
in an address parameter instead of splitting them. Don't know if that
matters here or not.

Ugh, aete calls, now there's a headache long forgotten...

Can you try using your params from an applescript?  To make sure the error
isn't in the EIMS call?

I also recall EIMS having the ability to accept user@domain for such calls,
in an address parameter instead of splitting them.  Don't know if that
matters here or not.


----- Original Message -----

>I think I'm closer. But now the error is "can't coerce the string
> "Paul.Smith" into a string4 because it isn't exactly 4 characters long."
>
> If I change the first set of params to the domain, I get the same error
> only it complains that the domain isn't string4
> There's a trick to this that I'm missing :-(
> Steve
>
>
> on steveNewUser (userName, domain, fullName, password, sizeLimit, accEn,
> loginEn) {
>    return (appleEvent (eims.id, 'EIMS', 'NEWU', '----', 'pANM', string
> (userName), 'pDMN', string (domain), 'pFNM', string (fullName), 'pPWD',
> string (password), 'pSIZ', string (sizeLimit), 'pAEN', boolean (accEn),
> 'pLGN', boolean (loginEn)))};
> bundle { // testing
>    local {
>        userName = "Paul.Smith";
>        domain = "educatr.com";
>        fullName = "Paul Smith";
>        password = "123456";
>        sizeLimit = 1024;
>        accEn = true;
>        loginEn = true};
>    steveNewUser (userName, domain, fullName, password, sizeLimit,
> accEn, loginEn)}

I think I'm closer. But now the error is "can't coerce the string
"Paul.Smith" into a string4 because it isn't exactly 4 characters long."

If I change the first set of params to the domain, I get the same error
only it complains that the domain isn't string4
There's a trick to this that I'm missing :-(
Steve


on steveNewUser (userName, domain, fullName, password, sizeLimit, accEn,
loginEn) {
     return (appleEvent (eims.id, 'EIMS', 'NEWU', '----', 'pANM', string
(userName), 'pDMN', string (domain), 'pFNM', string (fullName), 'pPWD',
string (password), 'pSIZ', string (sizeLimit), 'pAEN', boolean (accEn),
'pLGN', boolean (loginEn)))};
bundle { // testing
     local {
         userName = "Paul.Smith";
         domain = "educatr.com";
         fullName = "Paul Smith";
         password = "123456";
         sizeLimit = 1024;
         accEn = true;
         loginEn = true};
     steveNewUser (userName, domain, fullName, password, sizeLimit,
accEn, loginEn)}

I'm trying to add a new user to EIMS on Mac Classic. But, I cannot get
the string of parameters correct. I keep getting an error "Encountered
an unexpected data type."

Below is the script, and the three attempts I have had at getting the
formatting correct.

If someone can help, I'd be eternally thankful.
Steve


on newUser (x) { «Add a new user
     return (appleEvent (eims.id, 'EIMS', 'NEWU', '----', x))};
local {
     «x =
"\"username:\"richard.green\",domain:\"test.com\",fullname:\"Richard
Green\",password:\"a5tyhju\",loginEnabled:\"true\",accountEnabled:\"true\"\""
     «x =
"username:\"richard.green\",domain:\"test.com\",fullname:\"Richard
Green\",password:\"a5tyhju\",loginEnabled:\"true\",accountEnabled:\"true\""
     x =
{"username:\"richard.green\"","domain:\"test.com\"","fullname:\"Richard
Green\"","password:\"a5tyhj\"","loginEnabled:\"true\"","accountEnabled:\"true\""\
,"sizelimit:\"1024\""}};
newUser (x)

On 31 Aug 2009, at 02:31, dwiner wrote:
> He found a silent failure in the startup process in the OPML Editor,
> some very ancient code that dates back to when we had a very tight
> relationship with WebSTAR.

Actually, we had commented out the relevant script code in our version
of Frontier.root, so the bug wasn't triggered during the startup
process. Otherwise, I suspect it would have been fixed much earlier...

André



--
André Radke  ++  http://spicynoodles.net/

On 31 Aug 2009, at 05:54, Henri Asseily wrote:

> The svn log says "file.folderFromPath", not file.file.FromPath. Is
> that the same bug?

Yes, it is. There was a silent failure (execution stops but no
scripterror is generated) when file.folderFromPath received a nil
filespec, e.g. as returned by file.findApplication when it can't find
the requested application.

> Just checking to see if the svn trunk is the same one you're working
> off of.


It is, at least for the moment.

André


--
André Radke  ++  http://spicynoodles.net/

The svn log says "file.folderFromPath", not file.file.FromPath. Is
that the same bug?
Just checking to see if the svn trunk is the same one you're working
off of.

---
Henri Asseily
henri.tel




On Aug 30, 2009, at 8:31 PM, dwiner wrote:

> First, Andre is the best -- I've never worked with a better
> developer in all my years.
>
> He found a silent failure in the startup process in the OPML Editor,
> some very ancient code that dates back to when we had a very tight
> relationship with WebSTAR.
>
> The built-in verb file.fileFromPath would fail silently, killing the
> startup process, and it would never initialize inetd, and therefore
> the HTTP server wasn't running.
>
> That bug is now fixed. It's important that you all know about it
> because it very likely effects Frontier as well. My guess is that
> the built-in web server doesn't work there either but of course this
> change will fix it.
>
> There are more problems, but none as vexing as this one.
>
> I'm seeing the beachball cursor fighting with the arrow cursor
> constantly while I'm editing in the outliner. The editing still
> works but I won't be able to write using this build, it's that
> distracting.
>
> Dave
>

And I was able to kill the beachball cursor by returning false from
system.verbs.globals.rollBeachball.

Hey this shit is fun! :-)

Dave





--- In frontierkernel@yahoogroups.com, "dwiner" <dave@...> wrote:
>
> First, Andre is the best -- I've never worked with a better developer in all
my years.
>
> He found a silent failure in the startup process in the OPML Editor, some very
ancient code that dates back to when we had a very tight relationship with
WebSTAR.
>
> The built-in verb file.fileFromPath would fail silently, killing the startup
process, and it would never initialize inetd, and therefore the HTTP server
wasn't running.
>
> That bug is now fixed. It's important that you all know about it because it
very likely effects Frontier as well. My guess is that the built-in web server
doesn't work there either but of course this change will fix it.
>
> There are more problems, but none as vexing as this one.
>
> I'm seeing the beachball cursor fighting with the arrow cursor constantly
while I'm editing in the outliner. The editing still works but I won't be able
to write using this build, it's that distracting.
>
> Dave
>

First, Andre is the best -- I've never worked with a better developer in all my
years.

He found a silent failure in the startup process in the OPML Editor, some very
ancient code that dates back to when we had a very tight relationship with
WebSTAR.

The built-in verb file.fileFromPath would fail silently, killing the startup
process, and it would never initialize inetd, and therefore the HTTP server
wasn't running.

That bug is now fixed. It's important that you all know about it because it very
likely effects Frontier as well. My guess is that the built-in web server
doesn't work there either but of course this change will fix it.

There are more problems, but none as vexing as this one.

I'm seeing the beachball cursor fighting with the arrow cursor constantly while
I'm editing in the outliner. The editing still works but I won't be able to
write using this build, it's that distracting.

Dave

Well, that's good news! :-)

Regardless, at some point we're going to have to deal with this.

Dave

--- In frontierkernel@yahoogroups.com, Matt Neuburg <matt@...> wrote:
>
> On or about 8/26/09 9:29 AM, thus spake "frontierkernel@yahoogroups.com"
> <frontierkernel@yahoogroups.com>:
>
> > 1b. Re: Need help with Mac version of OPML Editor kernel
> >     Posted by: "André Radke" lists@... andre_radke
> >     Date: Tue Aug 25, 2009 1:34 pm ((PDT))
> >
> >
> > On 25 Aug 2009, at 21:53, matt neuburg wrote:
> >> Then you might understand it wrong. Nothing of any significance has
> >> changed in Snow Leopard (as opposed to Leopard) about running PPC-only
> >> apps. If it ran on an Intel box under Rosetta before, it runs on an
> >> Intel
> >> box under Rosetta in Snow Leopard. m.
> >
> >
> > I agree, except there's a rumour that Rosetta will not be part of the
> > default install in Snow Leopard:
> >
> > http://www.macfixit.com/article.php?story=20090813160052571
> >
> > I don't know whether this is true or not...
>
> I *do* know whether it's true or not, and (for reasons I can't discuss yet,
> but of course will be obvious to everyone in a day or two) I'm telling you
> that that's irrelevant in any case. Ignore rumors, stick to reality. m.
>
>
> --
> matt neuburg, phd = matt@..., http://www.tidbits.com/matt/
> pantes anthropoi tou eidenai oregontai phusei
> Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
> AppleScript: the Definitive Guide, 2nd edition
> http://www.tidbits.com/matt/default.html#applescriptthings
> Take Control of Customizing Leopard, http://tinyurl.com/2t9629
> TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
>

That's what I heard too.

I'm supporting users who may not want to turn Rosetta on.

I haven't gotten my copy of Snow Leopard yet, so I can't verify. It should come
on Monday.

Dave

> I agree, except there's a rumour that Rosetta will not be part of the
> default install in Snow Leopard:
>
> http://www.macfixit.com/article.php?story=20090813160052571
>
> I don't know whether this is true or not...
>
> André
>
>
>
> --
> André Radke  ++  http://spicynoodles.net/
>

With Andre's patient guidance, I have been able to build the OPML app here, and
most of it works, but...

Two problems so far, one cosmetic, one a deal-stopper.

1. At times the menu bar just goes gray. The menus are still there, but it's
disconcerting. Not a deal-stopper.

2. The HTTP server doesn't work. If I go to (for example)

http://127.0.0.1:5337/river2/

I get an error. I started debugging in builtins.inetd, the code hadn't been
changed since 2000, and was able to get a slight improvement. Now it just times
out.

This makes me wonder if the Intel build of Frontier that you all are using here
has a web server that works -- because my web server and yours appear to be
identical. I've made some very small changes to mainResponder, and maybe those
are responsible for the problems. But I thought it was worth asking.

One bit of good news -- almost everything else appears to be working, and it
feels zippier, though I have no tests yet to quantify the feeling.

On or about 8/26/09 9:29 AM, thus spake "frontierkernel@yahoogroups.com"
<frontierkernel@yahoogroups.com>:

> 1b. Re: Need help with Mac version of OPML Editor kernel
>     Posted by: "André Radke" lists@... andre_radke
>     Date: Tue Aug 25, 2009 1:34 pm ((PDT))
>
>
> On 25 Aug 2009, at 21:53, matt neuburg wrote:
>> Then you might understand it wrong. Nothing of any significance has
>> changed in Snow Leopard (as opposed to Leopard) about running PPC-only
>> apps. If it ran on an Intel box under Rosetta before, it runs on an
>> Intel
>> box under Rosetta in Snow Leopard. m.
>
>
> I agree, except there's a rumour that Rosetta will not be part of the
> default install in Snow Leopard:
>
> http://www.macfixit.com/article.php?story=20090813160052571
>
> I don't know whether this is true or not...

I *do* know whether it's true or not, and (for reasons I can't discuss yet,
but of course will be obvious to everyone in a day or two) I'm telling you
that that's irrelevant in any case. Ignore rumors, stick to reality. m.


--
matt neuburg, phd = matt@..., http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Customizing Leopard, http://tinyurl.com/2t9629
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com

On 25 Aug 2009, at 21:53, matt neuburg wrote:
> Then you might understand it wrong. Nothing of any significance has
> changed in Snow Leopard (as opposed to Leopard) about running PPC-only
> apps. If it ran on an Intel box under Rosetta before, it runs on an
> Intel
> box under Rosetta in Snow Leopard. m.


I agree, except there's a rumour that Rosetta will not be part of the
default install in Snow Leopard:

http://www.macfixit.com/article.php?story=20090813160052571

I don't know whether this is true or not...

André



--
André Radke  ++  http://spicynoodles.net/

> 1. Need help with Mac version of OPML Editor kernel
>     Posted by: "dwiner" dave@... dwiner
>     Date: Tue Aug 25, 2009 6:48 am ((PDT))
>
> Lots of new stuff underway with the OPML Editor, but we just tripped over
> a deadline -- on Friday Apple will release Snow Leopard, and as I
> understand it, running PPC apps will become problematic.

Then you might understand it wrong. Nothing of any significance has
changed in Snow Leopard (as opposed to Leopard) about running PPC-only
apps. If it ran on an Intel box under Rosetta before, it runs on an Intel
box under Rosetta in Snow Leopard. m.

Lots of new stuff underway with the OPML Editor, but we just tripped over a
deadline -- on Friday Apple will release Snow Leopard, and as I understand it,
running PPC apps will become problematic. I constantly get requests for an Intel
version of the OPML Editor app.

It's now beyond the nice-to-have level and is now must-have.

A few people from OPML Editor Land have ventured into this space, I think, or
perhaps someone here could help. I am busy working on rssCloud, a very exciting
project, with (once again) Frontier playing a central role. It's continuation of
work started in 2001. Already a lot of uptake and more on the way.

I've written a blog post this morning explaining the need.

http://www.scripting.com/stories/2009/08/25/urgentlyNeedAnIntelBuildOf.html

The OPML Editor is an open source project, and I can't do everything. I need
some help. Hopefully someone or some group of people will get together and
create a miracle -- an Intel build of the OPML Editor kernel.

Comments please on the blog post. TIA. :-)

Dave

Nice, Matt. Waiting for a morning where I've got a full coffee pot to watch the
video, but interesting to look at.

-- David

--- In frontierkernel@yahoogroups.com, Matt Neuburg <matt@...> wrote:
>
> No longer just talking about it; I've finally decided to release
> RubyFrontier into the wild.
>
> RubyFrontier is a TextMate bundle. It implements a Web site framework
> basically modelled after the UserLand Frontier Web site framework, written
> in Ruby.
>
> Documentation and description here:
>
> http://www.apeth.com/RubyFrontierDocs/default.html
>
> Incredibly great new screencast here (rather long, take it in stages or at
> least have a coffee machine sitting next to you the whole time):
>
> http://www.apeth.com/rubyFrontier.mov
>
> The download:
>
> http://sourceforge.net/projects/rubyfrontier/
>
> Share and enjoy. Tell a friend (if you have one).
>
> m.
>
> --
> matt neuburg, phd = matt@..., http://www.tidbits.com/matt/
> pantes anthropoi tou eidenai oregontai phusei
> Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
> AppleScript: the Definitive Guide, 2nd edition
> http://www.tidbits.com/matt/default.html#applescriptthings
> Take Control of Customizing Leopard, http://tinyurl.com/2t9629
> TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
>

No longer just talking about it; I've finally decided to release
RubyFrontier into the wild.

RubyFrontier is a TextMate bundle. It implements a Web site framework
basically modelled after the UserLand Frontier Web site framework, written
in Ruby.

Documentation and description here:

http://www.apeth.com/RubyFrontierDocs/default.html

Incredibly great new screencast here (rather long, take it in stages or at
least have a coffee machine sitting next to you the whole time):

http://www.apeth.com/rubyFrontier.mov

The download:

http://sourceforge.net/projects/rubyfrontier/

Share and enjoy. Tell a friend (if you have one).

m.

--
matt neuburg, phd = matt@..., http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Customizing Leopard, http://tinyurl.com/2t9629
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com

On Mon, Jul 6, 2009 at 9:24 PM, steve
harley<yahoo.20020228.groups@...> wrote:

> they whom i call Matt Neuburg wrote:
>>Then I discovered that Ruby likes to save structured
>> data as YAML.
>
> excellent -- looks like nested YAML outlines in key/value form
> are reasonable enough for my non-geek client to edit in BBEdit
> (which folds YAML nicely), with file system for higher level
> organization; it will cause some moaning, because tracking indent
> levels is not quite so intuitive, but it will work

Let me know if you run into any problems with BBEdit's YAML module. I
wrote it, I can fix it. (I know there are a couple bugs.)

Seth

they whom i call Scott S. Lawton wrote:
> Jumping in: it's not crazy to use Frontier for editing, then write the
> file to disk for Python/Ruby.  Many folks don't like editing text files.
>
> Or, as Matt mentioned, OmniOutliner for editing.

well, if i'm just using Frontier as an outline editor, i'd
probably choose OmniOutliner; either adds an export step, and as
i mentioned OmniOutliner can do key value pairs as columns; the
export step seems like a potential source of error however

> I haven't kept current: can Frontier still run AppleScript?  If so,
> isn't that a sufficient wrapper around AppleEvents?

it can; not sure if it has the endian problems; even if it
didn't, it would be quite a mess to wrap every Apple Event call
in my complex system; i've had some experience doing that to save
time converting old scripts and it wasn't pretty; there were also
problems passing complex objects to/from the embedded AppleScripts

> excellent -- looks like nested YAML outlines in key/value form
> are reasonable enough for my non-geek client to edit in BBEdit
> (which folds YAML nicely), with file system for higher level
> organization; it will cause some moaning, because tracking indent
> levels is not quite so intuitive, but it will work
>
> this is pretty much the last piece except for the client to reach
> the tipping point
>
> thanks a lot for the patient suggestions, Matt
>
> too bad for Frontier, though; i will miss the code editor
>

Jumping in: it's not crazy to use Frontier for editing, then write the
file to disk for Python/Ruby.  Many folks don't like editing text files.

Or, as Matt mentioned, OmniOutliner for editing.

Or, have Frontier invoke Python/Ruby which in turn send AppleEvents.

I haven't kept current: can Frontier still run AppleScript?  If so,
isn't that a sufficient wrapper around AppleEvents?

Scott

they whom i call Matt Neuburg wrote:
>Then I discovered that Ruby likes to save structured
> data as YAML.

excellent -- looks like nested YAML outlines in key/value form
are reasonable enough for my non-geek client to edit in BBEdit
(which folds YAML nicely), with file system for higher level
organization; it will cause some moaning, because tracking indent
levels is not quite so intuitive, but it will work

this is pretty much the last piece except for the client to reach
the tipping point

thanks a lot for the patient suggestions, Matt

too bad for Frontier, though; i will miss the code editor

> 1.2. Re: The future life of Frontier vs. migrating to other platforms
>     Posted by: "steve harley" yahoo.20020228.groups@...
> garbanzito_real
>     Date: Mon Jul 6, 2009 8:57 am ((PDT))
>
>
> i don't manage websites with Frontier, and it sounds like my use
> of the odb is not what you'd expect
>
> i have a very fine-grained ODB that my client needs to be able to
> edit conveniently; for example just one of the numerous book
> formatting configurations in my system exports as 1325 files and
> folders, nested 7 deep; all of the values are scalars or short
> strings
>
> this would translate well to Python dictionaries, with a fairly
> simple code translation path; i'm sure i could read a set of
> files into dictionaries, the problem is how to edit the files? i
> don't know anything as convenient as Frontier's odb editor

Yes, this puzzled me too, as I was contemplating writing RubyFrontier -
that's going back a couple of years now. At the time, as I saw that my hopes
for the Frontier Open Source project were not going to be realized, I
started to think about alternatives. At first I feared that I might have to
write some kind of Cocoa-based GUI front end to allow editing of some sort
of ODB-like structure. Then I discovered that Ruby likes to save structured
data as YAML.

http://www.yaml.org/

Saving out a "dictionary" (Ruby calls this a hash) to a text file, or
reading it back in, is a single brief line of code. Now you've got (wait for
it) a text file! With a good text editor, such as TextMate's YAML module,
that's easy to edit. And TextMate's wonderful project / folder editing
abilities make it easy to go after those files no matter how deeply they are
nested.

Just to give a simple example, here's how YAML and RubyFrontier save a web
site prefs table to a text file:

---
:renderoutlinewith: halo
:dreamweaver: false
:smartypants: true
:halo_shortcut: "|"
:haloautoparagraphs: true
:useImageCache: false
:includeMetaCharset: true
:stylesheetstyles: true
:includeMetaGenerator: true
:dolinkback: false
:markdown: true
:draft: false
:flatten: false

Look familiar? Look easy to edit?

So, as I say, I don't think there is anything special about the odb or about
Frontier's interface for editing it. YAML is all about configuration files -
configuration files that are edited as text but are then instantly read in
as complex data structures (like Frontier's tables). Look at Ruby on Rails
if you don't believe me.

At this point, the only thing Frontier does well that I miss is edit
outlines. But I just use another outliner (OmniOutliner, at the moment) and
save out as OPML. OPML is just XML (really crappy XML, but never mind), so
RubyFrontier can easily read it and parse it and Bob's your uncle.

I'm saying all this not to persuade you to use any particular tool. Others
have pointed out Python and various Python-based solutions. It doesn't
matter what you eventually use. I'm saying it because a couple of years ago,
I was where you are (I think). I felt trapped in the ODB. But the more I
began get my head out of the sand and to look into what was going on in the
real world, the more I began to understand that every part of the puzzle was
already a solved problem, and that Frontier wasn't doing *anything* on which
I was absolutely dependent.

m.

--
matt neuburg, phd = matt@..., http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Customizing Leopard, http://tinyurl.com/2t9629
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com

they whom i call Matt Neuburg wrote:
> As for "reliant on the object database", my experience is that that's a
> canard. I've found that just using the file system (a RubyFrontier web site
> is just files in folders) works just as well. I haven't found that the
> object database was in fact doing anything I really needed. I don't notice
> its absence; true hashes and arrays are way faster, and persistence is
> easily managed.

RubyFrontier has definitely caught my interest in past mentions ...

i don't manage websites with Frontier, and it sounds like my use
of the odb is not what you'd expect

i have a very fine-grained ODB that my client needs to be able to
edit conveniently; for example just one of the numerous book
formatting configurations in my system exports as 1325 files and
folders, nested 7 deep; all of the values are scalars or short
strings

this would translate well to Python dictionaries, with a fairly
simple code translation path; i'm sure i could read a set of
files into dictionaries, the problem is how to edit the files? i
don't know anything as convenient as Frontier's odb editor ...
while BBEdit (like TextMate) can navigate the hierarchy of a
folder nicely, it can show only one file at a time and it can't
cut and paste branches of the hierarchy like Frontier; the best
idea i've had yet is to use two OmniOutliner columns to represent
key and value (possibly a third for datatype?), and export to OPML

other suggestions welcome ...

> If you want to try to move your stuff over to RubyFrontier, or to assess the
> possibility of doing so, you are welcome to do so (feel free to contact me
> offline if you want a copy). m.

thanks, i may do so when i reach an appropriate point

On or about 7/5/09 2:58 PM, thus spake "frontierkernel@yahoogroups.com"
<frontierkernel@yahoogroups.com>:

> 1.2. Re: The future life of Frontier vs. migrating to other platforms
>     Posted by: "steve harley" yahoo.20020228.groups@...
> garbanzito_real
>     Date: Sat Jul 4, 2009 8:53 pm ((PDT))
>
> they whom i call Matt Neuburg wrote:
>> It sounds like this is a problem of sending Apple events, no? You might want
>> to look at appscript.
>
> that is indeed the biggest problem, and thanks for the
> suggestion; i've watched appscript mature for a few years,
> keeping it in mind for a point when the project needs to move
> forward and i can't work my way through the problem more easily
> in Frontier
>
> with appscript i could indeed do close to a line-for-line rewrite
> of the Apple Events code; however that code is intertwined with
> code reliant on the object database and html.processmacros; i
> have some good ideas for how to go about it (way OT), but i'm not
> looking forward to it (10-15 year old code ...)

Right, well, that is exactly why I wrote RubyFrontier - so that I could take
all my existing Frontier web sites, many of them very old, and rewrite them
in something that actually works, with a bare minimum of fuss. Since
RubyFrontier works almost exactly like Frontier (deliberately so), there is
very little to do in order to change a Frontier site into a RubyFrontier
site. All my sites are now maintained in RubyFrontier. Naturally,
RubyFrontier has a processmacros equivalent.

As for "reliant on the object database", my experience is that that's a
canard. I've found that just using the file system (a RubyFrontier web site
is just files in folders) works just as well. I haven't found that the
object database was in fact doing anything I really needed. I don't notice
its absence; true hashes and arrays are way faster, and persistence is
easily managed.

If you want to try to move your stuff over to RubyFrontier, or to assess the
possibility of doing so, you are welcome to do so (feel free to contact me
offline if you want a copy). m.

--
matt neuburg, phd = matt@..., http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Customizing Leopard, http://tinyurl.com/2t9629
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com

they whom i call Matt Neuburg wrote:
> It sounds like this is a problem of sending Apple events, no? You might want
> to look at appscript.

that is indeed the biggest problem, and thanks for the
suggestion; i've watched appscript mature for a few years,
keeping it in mind for a point when the project needs to move
forward and i can't work my way through the problem more easily
in Frontier

with appscript i could indeed do close to a line-for-line rewrite
of the Apple Events code; however that code is intertwined with
code reliant on the object database and html.processmacros; i
have some good ideas for how to go about it (way OT), but i'm not
looking forward to it (10-15 year old code ...)

> rb-appscript is very easy to learn if you are used to UserTalk's way of
> sending Apple events - especially because I've written an online "book"
> about it:

wow, lots of great detail in there; i've had py-appscript in
mind, but that's a great resource