Re: Making the move...
I agree. Useful discussion for things I'm thinking hard about these days as I move away from Ruby on Rails and look for Rev-centric approaches to the software projects I want to build. On 3/28/06, Sivakatirswami [EMAIL PROTECTED] wrote: I mean if the SSI ! include exec some rev.cgi. returns data to the HTML page instead of an HTML chunk, then you have the separation between views and data you describe, n'est pas? No? In the simplistic case, this is probably true. Where it breaks down is where we are retrieving data from a database (or for that matter from some other form of persistent storage) on the server and we need to create tables of dynamic data in the web page, for example. This requires the use of an iterator that encloses HTML formatting something like this: % order_line.line_items.each do |li| % div class=olitem span class=olitemqty%= li.quantity %/span span class=olitemtitle%= li.product.title %/span /div % end % The coder (developer) builds this construct and the HTML designer creates the definitions for the classes that define how s/he wants that kind of data displayed. But it's the iterator (the each do operation) that makes this possible. To make this happen with an SSI would, I think, be much more complicated if in fact it could be implemented at all. I think what I'm coming to is that an MVC framework, properly implemented, creates as nearly as possible a complete severance between content and presentation. CSS is one of the ways this is made even more efficient, but it is really the MVC architecture that provides the necessary support. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Dan Shafer wrote: Richard I agree that merge is very cool and quite powerful. Still, I cannot put into a Web page: Hello, there. The time is % merge [[the time]] % (regardless of the dellimiter being used around the call) as I can with Ruby. The merge operation would, I think, have to be included in the CGI generating the entire text string above, right? Or am I really missing something obvious here? The merge function can take any block of text (such as an HTML page, for example) and will replace Transcript expressions between [[ and ]] with the evaluated result. You can but any expression or container reference between those brackets, including variables, constants, or even calls to Transcript functions defined elsewhere, and you can place any number of these anywhere in your HTML. It really is worth devoting a half-hour to playing with. Merge is one of the best things Transcript adopted from SuperTalk (from back in the days when Allegiant was pushing a server-side engine). You can use the merge function in a CGI script, or in HTML templates processed by the engine, however you like. And just like the recommended Ruby setup, we have users on this list who set up Rev with FastCGI, so performance should be roughly on par with similarly configured systems. With Ruby it's common to create server directives that pass any files accessed in specified directories through Ruby on the way out (in essence an implied CGI), and I see no reason one couldn't do the same for any text processing engine they're using, such as Rev. So while it seems somewhat magical to use: http://www.domain.com/appstuff/ ...all that's really happening there is the server is set up to interpret that as: http://www.domain.com/appStuff/default.rb Set up similarly, you could just as easily set up the server to have implied default pages specified as belonging to Rev, so calling the directory above would be interpreted as: http://www.domain.com/appStuff/default.revhtml Again, as I said earlier, this may well be a distinction without a difference when it comes to accomplishing what I'm pointing out as the main advantage/feature of an MVC framework for Web development, namely the (relatively) clean separation between presentation and business logic. I'm not promoting Ruby, just trying to understand the qualitative difference in using an embedded scripting language vs. a CGI approach. Embedded is just how you set up your server to use the text processing engine of your choice, be it Ruby or Rev or whatever. Since Ruby is most commonly set up using FastCGI, any distinction between embedded and CGI may be too subtle to be instructive. But when you mention the framework, now you're on to the big difference that makes RoR attractive: Rails already exists, whereas one would need to write a well-factored web app framework in Rev to get the same level of productivity. MVC can make a good foundation for such a framework, as can many other common patterns. Anything that separates code, content, and presentation is a step in the right direction, esp. if it makes smart use of triggers and accessors as MVC and similar patterns do. As I noted here recently, I'm not yet convinced MVC per se is the best fit for Rev. I'm open to opinions to the contrary, and would enjoy learning about successful apps shipped with a Transcript implementation of MVC. Among languages that don't already provide MVC classes, there's much debate about how to graft them on. The more I look into it the more I find many different flavors of MVC, MV, and similar factored patterns. For example, there's at least one good paper outlining how Apple's MVC in Core Data differs from SmallTalk's. The biggest debates out there seems to focus on the scope and role of the Controller (most pretty much agree what a Model and a Viewer are), and a few have dropped the Controller altogether. I haven't had enough commercial experience with MVC to have a strong opinion about those differences. But stepping back from other people's implementation specifics to focus on the results we're all looking for, there are many ways to separate code, content, and presentation with Transcript. Couple that with the high productivity of Transcript's typelessness, chunk expressions, and merge function (just to name a few), Rev would seem a worthy contender for anything involving a lot of text processing, on the desktop or the server. PS: For a fun take on the flipside of frameworks, this post at Joel is a hoot: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your
Re: Making the move...
Richard Gaskin wrote: PS: For a fun take on the flipside of frameworks, this post at Joel is a hoot: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 Ha! Great stuff, really! Further down the page the author (IMO) does a great job of differentiating libraries vs frameworks. He states: I'd like to address the notion of using a framework vs. rolling your own framework. I think it's a false dichotomy; I don't want to use any framework at all. I know what several of you are thinking. I'd be out of my mind not to use some sort of framework. Am I honestly thinking of writing every single line of code that I'll need all on my own? No, of course not. What I'd really like to find are some appropriate *libraries* that I can use to provide several kinds of functionality for my project. Here's what I need: * A library to use as a templating system for the presentation tier of my application. This API should be dirt simple. * A library to use as a content repository (articles, essays, etc). * A library providing a user-management API, for creating, editing, and deleting users, and assigning them different privileges. * A library providing a threaded discussion forum API. This code should have *no* front-end gui. It should just provide an API of forum-related services that I'll need in building my webapp. I'll build my own JSP GUI on top of it. * A library providing multi-user blogging capabilities. Why is it so difficult to find simple libraries that provide these kinds of services? The distinction between a library and a framework is subtle, but I think critical. A library is a collection of code that I don't have to write myself. It provides me with a set of objects and methods that I can use to build me application. If the library doesn't do quite what I want, I can make some small modifications or throw it away and use a different library. A framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology. A library is something *contained* within my code. A framework is a *container* for my application. Interesting distinction... -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
HI Dan, I think the piece of the puzzle missing here is that of the web- server. It is easy to configure Apache (for example) to execute a particular program server-side when a page is requested that has a specific extension. This program is passed both the requested URL and resolved server-side path through the standard CGI environment variables PATH_INFO and PATH_TRANSLATED. For example, when put in the appropriate place something like: AddHandler rev_html .revhtml Action rev_html /cgi-bin/process_revhtml.cgi Will tell Apache to execute /cgi-bin/process_revhtml.cgi everytime a page with the extension .revhtml is accessed. (I wouldn't be surprised if this is how Ruby-on-Rails is actually configured, and is certainly how PHP or Perl is configured in some web-hosting environments where they didn't want to use mod_perl or mod_php for some reason). The process_revhtml.cgi script can then be something like: #! revolution -ui on startup local tInputScript put url (file: $PATH_TRANSLATED) into tInputScript local tOutputScript put merge(tInputScript) into tOutputScript write Content-Type: text/html return to stdout write Context-Length: the length of tOutputScript return to stdout write return to stdout write tOutputScript to stdout end startup So, a file on the webserver server such as 'current_time.revhtml' containing the following: html head titleCurrent Server Time/title /head body The current server time is [[the internet date]] /body /html Will serve a page saying something like: The current server time is Tue, 28 Mar 2006 10:55:01 + Of course, this is an incredibly simplistic example - but one that can be extended in a number of ways. Indeed, from this it is not hard to see how you could start to create an entire environment in which .revhtml scripts are run giving various features akin to PHP, Perl (with all its modules) and Ruby-on-Rails. Warmest Regards, Mark. -- Mark Waddingham ~ [EMAIL PROTECTED] ~ http://www.runrev.com Runtime Revolution ~ User-Centric Development Tools ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Some great information in the replies by Richard and Mark Waddingham here. Rather than quote them and intersperse comments, I thought I'd just make a point or two in response. Mark, you're right that the secret sauce here is training the Web server to route pages to specific processes based on file extensions. So a page ending in .revhtml or whatever could be mapped to invoke the Rev engine. I think that installing Ruby and RoR handles that file editing transparently, so it doesn't appear that there's any magic but there clearly is. Taking your advice, Richard, I spent another half hour with merge and I think the light is beginning to dawn for me. Based on my reading of the (rather sparse) docs, I *assumed* it would not work to try to execute abritrary code from inside those square brackets (or, as it turns out, using a return statment in the more conventional ? and ? delimiters, which Rev also supports). I'm not sure where the limitations are but a bit of experimenting revealed that I could get the following to work: put merge (It is now day [[line (dayOfWeek(the time)) of the weekdayNames]] in Monterey, California) into field htest Here, dayOfWeek is a function defined in the card script and the weekdayNames is a built-in system function that returns a list of the names of the days of the week, one per line. So I successfully executed a custom function call that used two bulit-in system functions (the time and the weekdayNames) and it worked. Clearly, then, I would be able to do this same thing in a .revhtml page on the server by invoking a Rev script after proper setup as described by Mark. The possibilities begin to become clearer now. I'm going to putter a bit more with this and see what I can come up with on my local (OS X Apache) Web server. I have it on good authority that Andre Garzia is going to have some very cool stuff along these lines to share with us in Monterey. I can hardly wait. Dan ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 27, 2006, at 8:10 AM, Dan Shafer wrote: That is where a Web app framework -- like Ruby on Rails, though there are several others worthy of consideration -- shows its strength. By adopting the model-view-controller (MVC) design paradigm, RoR creates an effective split between presentation and logic. The HTML designer works on views. The developer creates Controllers that look to Models for data they need to send to the views and for other logic that affects program execution. That bifurcation is important on non-trivial applications. A Web app framework that follows the MVC paradigm (or perhaps some other approach that provides the same division of labor) is preferable to CGI-based solutions which not only encourage but demand a mixing of the two somewhat incompatible skill sets. Dan, this is a good point, in my ignorance I may be making this all too simplistic, but is not the bifurcation a design decision? I mean if the SSI ! include exec some rev.cgi. returns data to the HTML page instead of an HTML chunk, then you have the separation between views and data you describe, n'est pas? No? And if Revolution is running as a daemon then even if you had 10 such SSI calls in a given web page, I don't see how this would be substantially different from having 10 merge statements embed in the page ... in fact, if separation between the vehicle (view) and the data in it (returned by SSI's) is important on non-trivial applications then doesn't putting the merge statements back into the html break that mandate? i.e. Marks solution puts the entire burden of the page development on the programmer and the HTML page designer is out cold. I mean doesn't a page like this elaborated to some thing more complex and really useful: html head titleCurrent Server Time/title /head body The current server time is [[the internet date]] /body /html take you right back here where you didn't want to be: This means, e.g., that the person writing the CGI must know HTML and the page design with which the CGI is designed to work. It also means that the HTML designer must typically be given access to the CGI code or, in the alternative, the CGI developer must be asked to hack HTML into the CGI itself. In both cases, we mix presentation and functionality in a way that is fraught with danger and maintenance issues. On the other hand, that problem set aside (even though, for me at least it *is* a core issue I face on a daily basis) I guess we can see that Marks model is fundamentally different than html head titleCurrent Server Time/title /head body The current server time is ! include exec=someRev.cgi /body /html where -- if you had ten of these includes in the page -- you are asking apache to call the CGI ten times. Yes, I too saw those warnings: But if a majority of your page is being generated at the time that it is served, you need to look for some other solution. But I just ignored them. We were not sophisticated enough to do a full on dBase web site and so SSI, was our only solution to global maintenance and separation of content from the DOM. And we really don't see any delivery time issues with pages that look like the ones below. Of course, it we had super heavy traffic it might be different. I'm actually thinking now of changing the entire model to using a dBase web site or XML-XSLT with flat files that regenerates the entire web site (or areas) that are 100% static code (no SSI's at all in the web pages at all) so then Apache has no work to do other than ship bytes. But, until SSI proves itself to be bad, and despite warnings I see no problems so far.. we will continue to use it. (aside: But what's happening is that the web site is now much more than just pages, it is an historical resource and in its present form, inaccessible. WE sell rights to some of the data engine companies, meanwhile we ourselves we don't even have a decent index. so I want to recast the content in a way that will make it much more useful... but I don't really know what direction to go in...) This is an excellent discussion, I find one of our regular challenges is how to open up channels to engage more people in the process of web content distribution, where the wiki and blog model is too open ended, and yet you need a UI where people can contribute directly. I would concur with Chipp about separating the framework and talking in terms of libraries...if you keep mucking around changing the framework your productivity will drop through the floor. Though my wish list of Libraries might be different, its the same need. A typical real world example could be someone who is responsible to inputting textual information (blog if you want to call it that, but it could be any kind of web page) and you want that to appear on a web page but you need to have
Re: Making the move...
OK, I've thought about this some more and poked at some of the CGIs you've developed. The place where this include virtual approach to Web site design breaks down for me comes at the point where, as I said in my original definition, we have embedded command and function calls in the underlying scripting language. Mind you, I'm not sure this isn't a distinction without a difference, but that was my intent in my earlier posts. I had, in fact, used SSI with the include virtual command a very long time ago and had shelved it, though I am no longer clear on the reason why I chose to do so at the time. Perhaps there are some downsides to using SSI that I'm forgetting. The Apache site's discussion of SSI includes this caveat: SSI is a great way to add small pieces of information, such as the current time. But if a majority of your page is being generated at the time that it is served, you need to look for some other solution. Perhaps that or something like it influenced me. In any case, what is clearly NOT happening with an SSI is the inclusion of Transcript commands or functions directly in the HTML file from which the dynamic page is generated. All of the Transcript code is external to the page layout/template. The overly simplistic example I provided earlier of using an embedded call to a built-in Ruby function such as Time.now() is the key idea here. The call to that function generates NO HTML code, just a value to be substituted into the HTML page when it's generated by the server. Using CGI, you can't mix HTML and operational code *in the HTML template or page*. This means in general that the CGI must generate HTML blocks to be inserted into the HTML page at generation time on the server. This means, e.g., that the person writing the CGI must know HTML and the page design with which the CGI is designed to work. It also means that the HTML designer must typically be given access to the CGI code or, in the alternative, the CGI developer must be asked to hack HTML into the CGI itself. In both cases, we mix presentation and functionality in a way that is fraught with danger and maintenance issues. That is where a Web app framework -- like Ruby on Rails, though there are several others worthy of consideration -- shows its strength. By adopting the model-view-controller (MVC) design paradigm, RoR creates an effective split between presentation and logic. The HTML designer works on views. The developer creates Controllers that look to Models for data they need to send to the views and for other logic that affects program execution. That bifurcation is important on non-trivial applications. A Web app framework that follows the MVC paradigm (or perhaps some other approach that provides the same division of labor) is preferable to CGI-based solutions which not only encourage but demand a mixing of the two somewhat incompatible skill sets. On 3/25/06, Dan Shafer [EMAIL PROTECTED] wrote: Sivakatirswami. Wow. I gotta go try this as soon as I finish this talk I'm giving tomorrow. And please send me those URLs you mentioned offlist. This could be HUGE for me. I had no idea this could be done and I don't know why I didn't have any idea this could be done. On 3/24/06, Sivakatirswami [EMAIL PROTECTED] wrote: Dan, if your definition of a web app really is: a Web *app* consists of a collection of 1 or more templates -- HTML files with embedded command and function calls -- that execute in a server-side scripting language interpreter running on the server. All Web pages with this embedded script code are run through the scripting language interpreter on the server, where the command is carried out and some content is generated to replace the command call before the page is sent to the HTTP server to return to the client. We are *already* doing this with Rev for several years now (and I'm pretty sure I'm not the only one, I got into this with Andu Novac when this was all metacard years ago... he still around?) and it works great, even without fastCGI...the fact that Rev is called on each hit doesn't seem to be an issue at all. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Dan Shafer wrote: In any case, what is clearly NOT happening with an SSI is the inclusion of Transcript commands or functions directly in the HTML file from which the dynamic page is generated. All of the Transcript code is external to the page layout/template. The overly simplistic example I provided earlier of using an embedded call to a built-in Ruby function such as Time.now() is the key idea here. The call to that function generates NO HTML code, just a value to be substituted into the HTML page when it's generated by the server. Using CGI, you can't mix HTML and operational code *in the HTML template or page*. This means in general that the CGI must generate HTML blocks to be inserted into the HTML page at generation time on the server. Just as Ruby is used to pre-process pages containing statements like time.now, you can use Rev as the preprocessor with its merge function to do the same thing: The time is [[the time]] The merge function is very powerful, well worth spending some time with if you want to use Rev like Ruby or PHP. The key thing to keep in mind when implementing a system like this is that Ruby is just a text processing engine. The methods by which it's hooked into the server are not unique to that engine, and just about any capable text processing engine, such as Rev, can be set up to be used in the same way. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Richard I agree that merge is very cool and quite powerful. Still, I cannot put into a Web page: Hello, there. The time is % merge [[the time]] % (regardless of the dellimiter being used around the call) as I can with Ruby. The merge operation would, I think, have to be included in the CGI generating the entire text string above, right? Or am I really missing something obvious here? Again, as I said earlier, this may well be a distinction without a difference when it comes to accomplishing what I'm pointing out as the main advantage/feature of an MVC framework for Web development, namely the (relatively) clean separation between presentation and business logic. I'm not promoting Ruby, just trying to understand the qualitative difference in using an embedded scripting language vs. a CGI approach. On 3/27/06, Richard Gaskin [EMAIL PROTECTED] wrote: Dan Shafer wrote: In any case, what is clearly NOT happening with an SSI is the inclusion of Transcript commands or functions directly in the HTML file from which the dynamic page is generated. All of the Transcript code is external to the page layout/template. The overly simplistic example I provided earlier of using an embedded call to a built-in Ruby function such as Time.now() is the key idea here. The call to that function generates NO HTML code, just a value to be substituted into the HTML page when it's generated by the server. Using CGI, you can't mix HTML and operational code *in the HTML template or page*. This means in general that the CGI must generate HTML blocks to be inserted into the HTML page at generation time on the server. Just as Ruby is used to pre-process pages containing statements like time.now, you can use Rev as the preprocessor with its merge function to do the same thing: The time is [[the time]] The merge function is very powerful, well worth spending some time with if you want to use Rev like Ruby or PHP. The key thing to keep in mind when implementing a system like this is that Ruby is just a text processing engine. The methods by which it's hooked into the server are not unique to that engine, and just about any capable text processing engine, such as Rev, can be set up to be used in the same way. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Sivakatirswami. Wow. I gotta go try this as soon as I finish this talk I'm giving tomorrow. And please send me those URLs you mentioned offlist. This could be HUGE for me. I had no idea this could be done and I don't know why I didn't have any idea this could be done. On 3/24/06, Sivakatirswami [EMAIL PROTECTED] wrote: Dan, if your definition of a web app really is: a Web *app* consists of a collection of 1 or more templates -- HTML files with embedded command and function calls -- that execute in a server-side scripting language interpreter running on the server. All Web pages with this embedded script code are run through the scripting language interpreter on the server, where the command is carried out and some content is generated to replace the command call before the page is sent to the HTTP server to return to the client. We are *already* doing this with Rev for several years now (and I'm pretty sure I'm not the only one, I got into this with Andu Novac when this was all metacard years ago... he still around?) and it works great, even without fastCGI...the fact that Rev is called on each hit doesn't seem to be an issue at all. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/21/06 4:55 PM, Sarah Reichelt [EMAIL PROTECTED] wrote: The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? Here is another way that you could take advantage of 'for each' and use one function, scanning the database one time, returning multiple results in one variable, without using an array. on scan --define var dbTable put dbScanner(dbTable) into dbEssence set the itemdel to ^ put item 1 of dbEssence into summer put item 2 of dbEssence into lister put item 3 of dbEssence into chimps end scan function dbScanner @dbTable set the itemDel to tab --if this is correct repeat for each line LNN in dbTable put , item 6 of LNN after itemsToSum put item 4 of LNN cr after listofItem4 if LNN contains circus monkey then put LNN cr after monkeyLines end if end repeat get sum(itemsToSum) filter listofItem4 without empty filter monkeyLines without empty return it ^ \ listofItem4 ^ \ monkeyLines end dbScanner Jim Ault Las Vegas On 3/21/06 4:55 PM, Sarah Reichelt [EMAIL PROTECTED] wrote: On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote: Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. OK, I have a better example. Say I have a data set and I need to loop through it and extract three different pieces of information e.g. a list of the 4th column in each line, a list of lines that match a certain set of criteria, and a cumulative total obtained by adding a certain column in each line. Each of these could be done in a separate function, but that would mean looping through the data set three times. With a large data set, it is significantly faster to loop once, filling all three new variables in the single loop. If I separate this off into a separate function, then I need a way of passing multiple results back. The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 16, 2006, at 8:13 AM, Richard Gaskin wrote: I would imagine one could also set up Apache to use Rev for server- side includes, using settings similar to what's used for Ruby or PHP. I'm coming in here late on this but it's of great interest and very relevant, because somehow, not really knowing any better I just stumbled on this two years ago and now we use SSI's which execute Rev CGI's throughout our web site. yes and double yes.. works great. Assuming you have a Rev Engine installed, CHMOD 755 and other cgi's are working. There is no set up required at all for SSI's !--#include virtual=/cgi-bin/get_story_listing.cgi -- or iFrame iframe name=archiveIndex border=0 width=130 height=140 src=/ cgi-bin/buildArchivesIndex.cgi We do not see *any* slow down. Of course those CGI's are not doing anything very complex. Maybe I'm way out of my depth here and what we are doing is very baby face compared with the kinds of things you are saying RoR can do ... On Mar 15, 2006, at 3:05 PM, Dan Shafer wrote: Furthermore, the execution of that CGI script would require an event to be sent via a form button or a JavaScript onLoad() command; it's not just automatic. With SSI exec it *is* automatic. I don't see any execution slow down. And there is no round trip to the client server client server that a JavaScript onLoad() does (I think) Dan, if your definition of a web app really is: a Web *app* consists of a collection of 1 or more templates -- HTML files with embedded command and function calls -- that execute in a server-side scripting language interpreter running on the server. All Web pages with this embedded script code are run through the scripting language interpreter on the server, where the command is carried out and some content is generated to replace the command call before the page is sent to the HTTP server to return to the client. We are *already* doing this with Rev for several years now (and I'm pretty sure I'm not the only one, I got into this with Andu Novac when this was all metacard years ago... he still around?) and it works great, even without fastCGI...the fact that Rev is called on each hit doesn't seem to be an issue at all. Of course my suexec log is crazy big and scary for tech support at the data center who threw up a Denial of Service Attack Underway-Change Your Root Password Now! red flag when they looked at it... You mean your web pages are calling those CGI's on every hit? Wow, if I tail the log those Revolution CGI's are executing every few milliseconds... But your site still blazes? Oh boy... I need to set up a cron to null that thing once a day! And, if you ssh in and run top.. the CPU shows it is still half a sleep... kustum Illai (Tamil) = no problem === OK Marty, for us poor we only know xTalk paupers if you are lurking... I've put up some CGI's on our site and sent you the URL off list (I don't want to post that on this forum... if anyone else wants to see them, ask me off list) Since I am a coding primitive you should be able to understand it all easily enough. In my old age I'm doing more commenting. The model (s) is very simple: if the CGI is an SSI then it executes and builds parts of the page before the page is sent. Nothing could be simpler. This usually involves fetching some template or code chunks in the SSI folder. I always try to avoid hard coding HTML in the CGI and almost always externalize even small chunks to small files. this has the advantage that you can delegate code maintenance... someone says Can I add a new link to the side bar and you say sure.. just add an liSome New link/li to this file and they never touch the CGI. And for icing on the coffee cake, and if you combine Rev cgi with XML and XSL you have some really interesting possibilities. Just go to this page: http://www.himalayanacademy.com/teaching/stories/ When you hit that page, the page itself re-builds the list of stories instantly... there is no round trip before the page is served. OK now go here: http://www.himalayanacademy.com/teaching/stories/enter_stories.shtml and enter a bogus story (no problem I will delete later, this site is not public, I mean it's not linked to any top pages, just put your name in there somewhere.) Now go back to http://www.himalayanacademy.com/teaching/stories/ and you will see your new story added to the list... click on your story.. viola, it comes back to you as a web page...tell me if you see the slightest delay in the service. Any PHP doing the same thing would be 2 to 5 times slower. I put all the related files to this little framework in the folder called stories. and the cgi emails me that a story was just entered... The input page takes form data, the rev CGI grabs an XML template pops in the data from the form, saves an XML document that calls an XSL stylesheet (that was actually the biggest learning
Re: Making the move...
at www.himalayanacademy.com and www.hinduismtoday.com we use *only* rev cgi's... and REvo remote clients But, I have also installed PMwiki which uses PHP. mod_php is presumably up and running all the time, but the rev engine is being loaded on each instance of a cgi being called. Nevertheless I can assure you, the Rev CGI beat the pants off PHP And we have some fairly complex CGI's in Rev, complex in the sense that they read templates from disk, replace place holder strings in the templates and send the web page back out. It really sparkles... while PMwiki, fast relative to other database based wikis, is sluggish compared to my Rev CGI's. FYI: but that is not enough (smile) we are going to set up a new web server in a couple of days, with a dual XEON processor at servePath with a 100mbps VPN socket to the switch (where our box is the *only* box on the Class C network before the router) and Andre will be figuring out how to install Fast_CGI behind Revolution on the new box...We can't wait to see how this thing will blaze! We will keep you all posted. I don't know any other language at all but Revolution... so all this talk about ajax and stuff is way over my head... maybe that's an advantage ifI you already have a Lear Jet, why do you need to know how to run a bi-prop? Hindu Press International is daily generated from the managing editor's, work station on, this Rev app builds the daily web pages, posts RSS feeds, send out email to the mailing list. I have a remote app deployed where voluteers can access the web server, download sound files, they do their work, the application uploads transcripts, opens the XML file in their browser, sends me and email... I mean *why* on earth do you even *want* to use an app inside a browser. If you *need* to access the web, which is not a bad thing.. then just send the to the browser to do what browsers do: display HTML: a librarian for static resources and leave it there. We use parsed web page templates (heavy use of SSI's) on all our sites and with ! include exec=/cgi-bin/someRev.cgi you can do some very interesting things. For example, at www.himalayanacademy.com the side bar links for any web pages on in any area on the web site are dynamically chosen based on the location of the web page. It's very cool and utterly simple, because it means that our web editors can take one template, use it for any web page in any location and he will get the local area navigation automatically installed depending on where the web page is placed. www.himalayanacademy.com/taka/ see the little archive iFrame, down on the right side of the page. This is another very interesting use of Rev...where the CGI installs an interactive calendar object (so to speak) into the iFrame, dynamically. it's basically an embedded object... and if it were JAVA who know where you could go with it. my point here is similar to Wally's: I'm not a developer, in any given day we have a *lot* of other things happening. Somehow with Rev, I can build all this in house and RAD stuff without breaking your head on small coding issues for days and days. If my manager editor comes to me with a small feature request for the Hindu Press International app I built... With transcript it always seems like it's a rare day when you cannot solve a problem or figure out how to get something done in less than ten minutes... and then keep moving forward. meanwhile, every time I open the PHP config files for the web wiki, I start to get a headache right away (smile)... I mean... I *can* figure it out...but, it's just like one has to keep groking that code all, while with transcript, you just think and do it. If Anyone wants to see our CGI's I would be happy to put them somewhere. Because I am not a developer, they could be easy for newbies to re-use. I see a lot of different places not where this kind of offering could be posted and one doesn't know which is best. And last but not least, to affirm Richard's observations with real life testimony (I think I posted some of this once before) While only useful in a subset of scenarios, it offers many benefits, esp. for intranets where employers are losing billions in lost productivity by providing open web access to their employees when all they really need is access to specific company- and vendor- specific resources. *confirmed!*: This week we see another case of the trend..Away from browsers We have a xerox Printer copier proofing machine here and Xerox used to deploy a browser based, UI, that users on the LAN would open in IE or Firefox (didn't work in Safari) to *see* the printer across the LAN, the printer is using a truncated linux OS on the FIERY.. well that thing was so buggy and broken... Well guess what? Their reps came by this week to tell us. Our engineers at Xerox abandoned the web based Java UI and we
Re: Making the move...
Sivakatirswami wrote: If Anyone wants to see our CGI's I would be happy to put them somewhere. Because I am not a developer, they could be easy for newbies to re-use. I see a lot of different places not where this kind of offering could be posted and one doesn't know which is best. Thanks for sharing what's happening with you - very inspiring. Personally, I would love to take a look at what you've put together. I'm just in the middle of Jacque's great cgi tutorial and am eager to learn all I can about Rev CGIs. I've recently applied for a couple of web developer jobs (one at out local university) but a downfall for me is that I don't program in Perl or PHP, and can't seem to get motivated to do so. It would be great to see Rev become more well know for this dimension of its vast capabilities. Marty Knapp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
First, this isn't all that long -- 98 lines -- but in any case I'd consider: -- breaking out routines for local vs. server connection -- breaking out a routine for when we're just counting records that match vs. returning data -- breaking out a routine that, given a itemList describing a set of fields, returns the data from those fields Some of the rest I'm still not clear on, so it's hard to say. As I said, more art than science, but to me a routine like this is more than five times as difficult to understand/debug/manage than the five twenty line routines that might replace it. Not that I haven't written my fair share of these ;-) regards, Geoff On Mar 21, 2006, at 11:59 AM, Rob Cozens wrote: Hi Geoff , Wow -- so what does this do? From Serendipity Reference: The findSDBRecord command checks for the existence locked/ unlocked status of a record with the record type and key specified in line 1 of sdbBuffer. It can also be used to unlock a record that was previously locked but not changed or to return a count of the number of records with certain field contents. findSDBRecord is undoubtedly the most complex, but also the most powerful, SDB command. It is the only SDB command that will retrieve information from multiple records in a single call. As such, it is ideally suited to retrieve specified fields from a range of records for reporting or analysis. exactKey (boolean) defaults to true, in which case findSDBRecord returns card id 0 if the exact key is not in the database; otherwise findSDBRecord will return the id for the record with the closest higher key of the specified record type. If fieldDelimiter is empty findSDBRecord simply returns the Revolution card id of the record in word 4 of the result. If fieldDelimiter is not empty, itemList contains a list of field references (one per line) to retrieve. A field reference can take two forms: * a number that resolves to the field's ordinal position in the record (0 = the record key) * an SDB field reference ([Record Type]:[dataname]), which the SDB handlers will resolve to a field ordinal. These two forms of reference can be used interchangably EXCEPT for record types that have no Dictionary definition in the database. findSDBRecord then puts a delimited list of the contents of the fields into lines 2 to -1 of sdbBuffer. setPosition (boolean) defaults to true. unlockRecord (boolean) defaults to false. If true and the record was locked by this user, it will be removed from the locked record table. findSDBRecord can be passed search criteria that must be met before a record is retrieved, and instructed to search forward or backward from the key if the key's record does not meet the search criteria until the first acceptable record is found. searchForward (boolean) determines search direction; default is true (forward). searchCriteria contains one or more lines in the following format: -- field reference,test,target,and/or * field reference is the field's ordinal or Data Dictionary name, as defibed above. * tests: = , ,in, not in, , , =, or = * target is the result to which the item is to be compared; it must be a value, not a reference to another field in the record * and or or is not needed on last line of search criteria Example search criteria (assumes the field is defined in Record Type, TYPE as dataname department): TYPE:department,,21,and TYPE:department,,34 Selects only records where the value of field department is between 22 and 33. If cutoffKey is not empty, findSDBRecord will discontinue the search when it encounters a record with a key cutoffKey if searching forward or cutoffKey if searching backward; otherwise the search will end with the first matching record if recordDelimiter is empty or the last/first record if it is not. If recordDelimiter is empty, findSDBRecord returns information for the first matching record it encounters. If recordDelimiter is not empty, findSDBRecord puts empty into sdbBuffer and returns the number of records matching the search criteria in word four of the rersult if the fieldDelimiter is empty; otherwise it returns the information for each matching record found between the key passed in sdbBuffer and cutoffKey or the last/first record of the specified record type. This information will be found in lines 2 to -1 of sdbBuffer. (The recordDelimiter is used to delimit individual records.) Note that findSDBRecord will return a locked record error if the record exists but is locked by another user. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe,
Re: Making the move...
Sarah Reichelt wrote: OK, I have a better example. Say I have a data set and I need to loop through it and extract three different pieces of information e.g. a list of the 4th column in each line, a list of lines that match a certain set of criteria, and a cumulative total obtained by adding a certain column in each line. Each of these could be done in a separate function, but that would mean looping through the data set three times. With a large data set, it is significantly faster to loop once, filling all three new variables in the single loop. If I separate this off into a separate function, then I need a way of passing multiple results back. The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? I'd probably use parameters by reference for each of the result values. To me, that's one of the good ways to use pass by ref. But if you didn't want to do that, and also didn't want to use an array, you could perhaps return a list of the result values. If you can find one more character that you can be sure won't appear in the results, simply use it to concatenate the results. For example: function getThreeThings pFrom . return tOne numtochar(3) tTwo numtochar(3) tThree end getThreeThings and when you call it put getThreeThings(tData) into temp set the itemDel to numtochar(3) put item 1 of temp into t1 put item 2 of temp into t2 etc. btw - when are Rev going to implement the etc. keyword ? -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.2.6/286 - Release Date: 20/03/2006 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hi Geoff, -- breaking out routines for local vs. server connection You're ignoring my notes: application requirement: the calling syntax must be identical for client, server, and single user. -- breaking out a routine for when we're just counting records that match vs. returning data Why? It is not used anywhere else but in this handler. Like Chipp, if I find a need for the logic in another handler, I'll generalize it. -- breaking out a routine that, given a itemList describing a set of fields, returns the data from those fields Why? It is not used anywhere else but in this handler. Like Chipp, if I find a need for the logic in another handler, I'll generalize it. And actually, theSDRecordMatches function handles most of that logic. to me a routine like this is more than five times as difficult to understand/debug/manage than the five twenty line routines that might replace it. Where's the beef! Show me the money! Divide findSDRecord into five twenty-line routines and post the result. I must say, Geoff, you seem to have a penchant for splitting handlers when there is no need to do so. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 22, 2006, at 7:34 AM, Rob Cozens wrote: Hi Geoff, -- breaking out routines for local vs. server connection You're ignoring my notes: application requirement: the calling syntax must be identical for client, server, and single user. That's fine -- I'm just saying that the routine would look something like: on doSomething pArg if tSingleUser then doSomethingForSingleUser pArg else doSomethingForMultiUser pArg end if end doSomething pArg This way the user can call the routine without regard to whether it's single user or multiuser, but you don't have two big chunks of code lumped together in one handler that can easily be separated. -- breaking out a routine for when we're just counting records that match vs. returning data Why? It is not used anywhere else but in this handler. Like Chipp, if I find a need for the logic in another handler, I'll generalize it. Because it gets rid of a bunch of if statements in your repeat loop. It costs you a bit in that the repeat structure is duplicated in the routine that simply counts, so that's a tradeoff. But your repeat ends up being faster because you aren't doing tests each time through. Further, your code ends up being easier to understand, because one routine simply counts, while one returns data -- more clear. -- breaking out a routine that, given a itemList describing a set of fields, returns the data from those fields Why? It is not used anywhere else but in this handler. Like Chipp, if I find a need for the logic in another handler, I'll generalize it. And actually, theSDRecordMatches function handles most of that logic. Just because something isn't used anywhere else doesn't mean it should be lumped in. If it can be clearly expressed as a single action (given an itemList describing a set of fields, return the data from those fields) it can be broken out, and both routines will be easier to understand as a result. to me a routine like this is more than five times as difficult to understand/debug/manage than the five twenty line routines that might replace it. Where's the beef! Show me the money! Divide findSDRecord into five twenty-line routines and post the result. I must say, Geoff, you seem to have a penchant for splitting handlers when there is no need to do so. I obviously don't know SDB well enough to: -- know what's right for it by my standards -- know what's right for it by your standards -- change code (or propose changes) in it without knowing the context in which the code operates I thought a bit before offering comment. Maybe not long enough ;-) If I've offended, I apologize. It wasn't my intention to cast stones at anyone's house in particular. If you can indulge me for just a moment longer, though, I'd like to throw out an analogy. Look at your comments above. The same thing could have been said as: On Mar 22, 2006, at 7:34 AM, Rob Cozens wrote: Hi Geoff, You're ignoring my notes: application requirement: the calling syntax must be identical for client, server, and single user. Why? It is not used anywhere else but in this handler. Like Chipp, if I find a need for the logic in another handler, I'll generalize it. Why? It is not used anywhere else but in this handler. Like Chipp, if I find a need for the logic in another handler, I'll generalize it. And actually, theSDRecordMatches function handles most of that logic. Where's the beef! Show me the money! Divide findSDRecord into five twenty-line routines and post the result. I must say, Geoff, you seem to have a penchant for splitting handlers when there is no need to do so. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) Breaking up your comments into paragraphs doesn't change the meaning of what you said, but it makes it clearer. regards, Geoff ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Geoff, -- breaking out routines for local vs. server connection Client selection [server opens all dbs as local connections]: replace return with numToChar(29) in itemList replace return with numToChar(29) in searchCriteria requestSDBService sdbBuffer,find,packArguments(9,exactKey,fieldDelimiter,itemList,setPos ition,searchForward,searchCriteria,cutoffKey,recordDelimiter,unlockRecor d) get the result if not word 1 of it and setPosition then put word 4 of it into sdbPosition put it into sdbParameters return it Every db access call has similar logic, but the second and third arguments are unique. To generalize: replace return with numToChar(29) in itemList replace return with numToChar(29) in searchCriteria put packArguments(9,exactKey,fieldDelimiter,itemList,setPosition,searchForwa rd,searchCriteria,cutoffKey,recordDelimiter,unlockRecord) into packedArguments doGeoffsHandler sdBuffer,find,packedArguments return the result on doGeoffsHandler @sdBuffer,serviceType,packedArguments requestSDBService sdbBuffer,serviceType,packedArguments get the result if not word 1 of it and setPosition then put word 4 of it into sdbPosition put it into sdbParameters return it end doGeoffsHandler I've saved two lines in the original handler...for what--the need to look up another handler to see the full picture? Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Geeze Geoff ,
If I've offended, I apologize.
I thought you knew me better than that. :{`)
If I've come off pedantic or emotionally upset, then I'm sorry.
There is no right or wrong answer, it's a matter of preference...and my
preferences are closer to Chipp's than yours in this matter.
Your friend, Cousin Rob
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Geoff: on doSomething pArg if tSingleUser then doSomethingForSingleUser pArg else doSomethingForMultiUser pArg end if end doSomething pArg doSomethingForMultiUser pArg is the seven lines I used as an example in my last post, the remaining 90 lines comprise doSomethingForSingleUser pArg Rob ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Geoff, Because it gets rid of a bunch of if statements in your repeat loop. It costs you a bit in that the repeat structure is duplicated in the routine that simply counts, so that's a tradeoff. But your repeat ends up being faster because you aren't doing tests each time through. Further, your code ends up being easier to understand, because one routine simply counts, while one returns data -- more clear. The function here is to count, and optionally select data from, records that match search criteria. To count and select in separate logic means parsing all records twice. I did find this logic: repeat for each line itemNumber in itemList put sdbFieldNumber(itemNumber) into itemNumber that should be evaluated once all error checks are passed: put empty into rawItemNumbers repeat for each line itemNumber in itemList put sdbFieldNumber(itemNumber)return after rawItemNumers end repeat put rawItemNumers into itemList and removed from the repeat loop...thanks. Other than that, I don't see much efficiency to be gained here. Also, if you look closely at if countOnly statements, you will find that they are in repeat exit logic, and never get executed more than once. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Sarah, Mark, et al: arrays are things that don't come naturally to me, so I probably ignore them when they would be useful. Arrays, in the traditional sense (ie: element(1)...element(n)), were part and parcel of my programming instruction in BASIC and my first professional programming in FORTRAN; but I rarely use them today. But Transcript keyed arrays make wonderful run-time tables. SDB Client/Server uses: local clientDbList -- array by clientId:dbId1, dbId2, etc local dbClientList -- array by dbId:client id,writeAccessType,current position local indexList -- array by dbId:cardIndex local lockedRecordList -- array by dbId: record id, client id local sdbDbPathList -- array by dbId: db stack path, autoLockOn, readLocksEnforced local sdbFieldDelimiter -- array by record type local sdbFieldEdits -- array by record type local sdbFieldList -- array by recordType: field name list local sdbTranslationList -- array by clientId: 1=ASCIIANSI, 0=None, or -1=ANSIASCII + tab ipcProtocol [tp,ae,pc,dc,sf] so... clientDbList[sdbClientId] gives me a list of the ids of all dbs the client has open dbClientList[sdbDbId] gives me a list of all clients using the db, including access type current record position indexList[sdbDbId] gives me the index to the db lockedRecordList[sdbDbId] gives me a list of the ids of all locked records along with the id of the user with the lock etc. I find this very powerful and easier to implement than alternative syntax. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 20, 2006, at 6:20 PM, Sarah Reichelt wrote: I haven't ever really tested it and I have an instinctive feeling that functions should be self-sufficient and shouldn't change anything outside them. Maybe it will suit me better in some circumstances. This is true, but passing by reference doesn't violate this, depending on how it's used. If you have a clear-cut function that operates on a value passed by reference because of its size, that's not a bad thing I don't think. gc ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Wow -- so what does this do? On Mar 20, 2006, at 9:28 AM, Rob Cozens wrote: Hi Geoff, Out of curiosity, do you have an example handy of a long handler that you think makes more sense to keep together than to break up? Or one that you think can't be broken up without significant effort to do it? on findSDBRecord @sdbBuffer,exactKey,fieldDelimiter,itemList,setPosition,searchForward, searchCriteria,cutoffKey,recordDelimiter,unlockRecord -- 28 Feb 04:RCC if ipcMode is not dc then -- dc = single user direct connection replace return with numToChar(29) in itemList replace return with numToChar(29) in searchCriteria requestSDBService sdbBuffer,find,packArguments (9,exactKey,fieldDelimiter,itemList,setPosition,searchForward,searchCr iteria,cutoffKey,recordDelimiter,unlockRecord) get the result if not word 1 of it and setPosition then put word 4 of it into sdbPosition put it into sdbParameters return it else if invalidSDBClient() then return truereturnsdbMessage (sdbInvalidClientError,true) if offset(returnsdbDbIdreturn,return(the keys of indexList) return) = 0 then return truereturnsdbMessage(sdbDbIdError,true) if exactKey is empty then put true into exactKey put (fieldDelimiter is not empty) into retrieveData if recordDelimiter is not empty then put true into multipleRecords put false into unlockRecords put false into setPosition else put false into multipleRecords put (multipleRecords and not retrieveData) into countOnly if setPosition is empty or retrieveData then put true into setPosition if searchForward is empty then put true into searchForward put ((sdbWriteAccess is Shared) and (unlockRecord is true)) into unlockRecord put word 2 to 4 of sdbParameters into savedPosition put justifyString(word 1 of sdbBuffer,4) into theRecordType getSDBRecord sdbBuffer,exactKey,,,setPosition,retrieveData get the result put word 2 to -1 of line 1 of sdbBuffer into recordKey if word 1 of it or (((recordKey cutoffKey and searchForward) or (recordKey cutoffKey and not searchForward)) and cutoffKey is not empty) then put falsesavedPosition into sdbParameters put false0 0 0 into line 1 of it return it else if unlockRecord and sdbWriteAccess is Shared then deleteDbLock(word 4 of sdbParameters) if not retrieveData and not multipleRecords then put it into sdbParameters return it end if end if put word 4 of sdbParameters into oldPosition put empty into returnRecord put 0 into recordCount repeat put word 2 to -1 of line 1 of sdbBuffer into recordKey if (recordKey cutoffKey and searchForward) or (recordKey cutoffKey and not searchForward) then put false into word 1 of sdbParameters if countOnly then put empty into sdbBuffer return (word 1 to 3 of sdbParameters)recordCount else put theRecordTyperecordCountreturnreturnRecord into sdbBuffer return (word 1 to 3 of sdbParameters)0 end if end if delete line 1 of sdbBuffer if theSDBRecordMatches (sdbBuffer,fieldDelimiter,searchCriteria) then add 1 to recordCount repeat for each line itemNumber in itemList put sdbFieldNumber(itemNumber) into itemNumber if itemNumber = 0 then put recordKeyfieldBelimiter after returnRecord else put getItem(itemNumber,fieldDelimiter,sdbBuffer) fieldDelimiter after returnRecord end repeat if multipleRecords then put recordDelimiter after returnRecord else put theRecordTyperecordKeyreturnreturnRecord into sdbBuffer return (word 1 to 3 of sdbParameters) end if end if set cursor to busy if searchForward then if word 2 of sdbParameters word 3 of sdbParameters then put + into sdbBuffer getSDBRecord sdbBuffer,exactKey,,,true,retrieveData put the result into sdbParameters else put true into sdbParameters else if word 2 of sdbParameters 1 then put - into sdbBuffer getSDBRecord sdbBuffer,exactKey,,,true,retrieveData put the result into sdbParameters else put true into sdbParameters end if if word 1 of sdbParameters then put false into word 1 of sdbParameters put oldPosition into word 4 of sdbParameters if countOnly then put empty into sdbBuffer return (word 1 to 3 of sdbParameters)recordCount else put theRecordTyperecordCountreturnreturnRecord into sdbBuffer return (word 1 to 3 of sdbParameters)0 end if else if not setPosition then put oldPosition into word 4 of sdbParameters end repeat end if end findSDBRecord Note: stack local variables and constant declarations excluded. application
Re: Making the move...
Hi Geoff , Wow -- so what does this do? From Serendipity Reference: The findSDBRecord command checks for the existence locked/unlocked status of a record with the record type and key specified in line 1 of sdbBuffer. It can also be used to unlock a record that was previously locked but not changed or to return a count of the number of records with certain field contents. findSDBRecord is undoubtedly the most complex, but also the most powerful, SDB command. It is the only SDB command that will retrieve information from multiple records in a single call. As such, it is ideally suited to retrieve specified fields from a range of records for reporting or analysis. exactKey (boolean) defaults to true, in which case findSDBRecord returns card id 0 if the exact key is not in the database; otherwise findSDBRecord will return the id for the record with the closest higher key of the specified record type. If fieldDelimiter is empty findSDBRecord simply returns the Revolution card id of the record in word 4 of the result. If fieldDelimiter is not empty, itemList contains a list of field references (one per line) to retrieve. A field reference can take two forms: * a number that resolves to the field's ordinal position in the record (0 = the record key) * an SDB field reference ([Record Type]:[dataname]), which the SDB handlers will resolve to a field ordinal. These two forms of reference can be used interchangably EXCEPT for record types that have no Dictionary definition in the database. findSDBRecord then puts a delimited list of the contents of the fields into lines 2 to -1 of sdbBuffer. setPosition (boolean) defaults to true. unlockRecord (boolean) defaults to false. If true and the record was locked by this user, it will be removed from the locked record table. findSDBRecord can be passed search criteria that must be met before a record is retrieved, and instructed to search forward or backward from the key if the key's record does not meet the search criteria until the first acceptable record is found. searchForward (boolean) determines search direction; default is true (forward). searchCriteria contains one or more lines in the following format: -- field reference,test,target,and/or * field reference is the field's ordinal or Data Dictionary name, as defibed above. * tests: = , ,in, not in, , , =, or = * target is the result to which the item is to be compared; it must be a value, not a reference to another field in the record * and or or is not needed on last line of search criteria Example search criteria (assumes the field is defined in Record Type, TYPE as dataname department): TYPE:department,,21,and TYPE:department,,34 Selects only records where the value of field department is between 22 and 33. If cutoffKey is not empty, findSDBRecord will discontinue the search when it encounters a record with a key cutoffKey if searching forward or cutoffKey if searching backward; otherwise the search will end with the first matching record if recordDelimiter is empty or the last/first record if it is not. If recordDelimiter is empty, findSDBRecord returns information for the first matching record it encounters. If recordDelimiter is not empty, findSDBRecord puts empty into sdbBuffer and returns the number of records matching the search criteria in word four of the rersult if the fieldDelimiter is empty; otherwise it returns the information for each matching record found between the key passed in sdbBuffer and cutoffKey or the last/first record of the specified record type. This information will be found in lines 2 to -1 of sdbBuffer. (The recordDelimiter is used to delimit individual records.) Note that findSDBRecord will return a locked record error if the record exists but is locked by another user. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote: Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. OK, I have a better example. Say I have a data set and I need to loop through it and extract three different pieces of information e.g. a list of the 4th column in each line, a list of lines that match a certain set of criteria, and a cumulative total obtained by adding a certain column in each line. Each of these could be done in a separate function, but that would mean looping through the data set three times. With a large data set, it is significantly faster to loop once, filling all three new variables in the single loop. If I separate this off into a separate function, then I need a way of passing multiple results back. The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
You might put the multiple results into the elements of an array, and return the array. Mark On 22 Mar 2006, at 00:55, Sarah Reichelt wrote: On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote: Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. OK, I have a better example. Say I have a data set and I need to loop through it and extract three different pieces of information e.g. a list of the 4th column in each line, a list of lines that match a certain set of criteria, and a cumulative total obtained by adding a certain column in each line. Each of these could be done in a separate function, but that would mean looping through the data set three times. With a large data set, it is significantly faster to loop once, filling all three new variables in the single loop. If I separate this off into a separate function, then I need a way of passing multiple results back. The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
I didn't think of that Mark. Again, arrays are things that don't come naturally to me, so I probably ignore them when they would be useful. In this case, it sounds like a really good solution. Thanks, Sarah On 3/22/06, Mark Smith [EMAIL PROTECTED] wrote: You might put the multiple results into the elements of an array, and return the array. Mark On 22 Mar 2006, at 00:55, Sarah Reichelt wrote: On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote: Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. OK, I have a better example. Say I have a data set and I need to loop through it and extract three different pieces of information e.g. a list of the 4th column in each line, a list of lines that match a certain set of criteria, and a cumulative total obtained by adding a certain column in each line. Each of these could be done in a separate function, but that would mean looping through the data set three times. With a large data set, it is significantly faster to loop once, filling all three new variables in the single loop. If I separate this off into a separate function, then I need a way of passing multiple results back. The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
I'm just a simple Caveman programmer. Your advanced technology and talk of arrays and multiple functions frighten me. In this case, I'd just as soon keep thinkgs in a single handler which cavemen like me can read and debug easily. :-) -Chipp Sarah Reichelt wrote: I didn't think of that Mark. Again, arrays are things that don't come naturally to me, so I probably ignore them when they would be useful. In this case, it sounds like a really good solution. Thanks, Sarah On 3/22/06, Mark Smith [EMAIL PROTECTED] wrote: You might put the multiple results into the elements of an array, and return the array. Mark On 22 Mar 2006, at 00:55, Sarah Reichelt wrote: On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote: Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. OK, I have a better example. Say I have a data set and I need to loop through it and extract three different pieces of information e.g. a list of the 4th column in each line, a list of lines that match a certain set of criteria, and a cumulative total obtained by adding a certain column in each line. Each of these could be done in a separate function, but that would mean looping through the data set three times. With a large data set, it is significantly faster to loop once, filling all three new variables in the single loop. If I separate this off into a separate function, then I need a way of passing multiple results back. The alternatives that I see are to use script local variables or to pass an empty parameter by reference and have the function fill it. Does anyone have any other ideas or recommendations? Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Out of curiosity, do you have an example handy of a long handler that you think makes more sense to keep together than to break up? Or one that you think can't be broken up without significant effort to do it? When you think of a long handler, do you generally think of it as having a single identifiable task, or do you think of it as being several tasks performed in sequence in one handler? Obviously it's possible that you simply think in bigger chunks ;-) On Mar 19, 2006, at 3:57 PM, Chipp Walters wrote: Yep, I've heard that before, but frankly, for me, I'd rather keep it all in one, unless there's a really good reason to separate into multiple handlers (as in creating more reusability). I find it much easier to debug code I've written this way than hunting through the message path for the 15 or so functions/handlers I've written trying to make things 'more simple.' Just a difference in coding style. In fact, typically I'll write code procedurally in a longer handler, then only break it up if/when I know I need to do part of the same thing again. Like most of us, I'd rather not code twice. Even though, I've got libraries with over 50 handlers/functions. -Chipp Mark Wieder wrote: Geoff- Saturday, March 18, 2006, 1:24:50 PM, you wrote: I've never seen a hundred-line routine that wouldn't be better as five twenty-line routines, each of which could be documented with a line of code. Perhaps even ten ten-line routines. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Making the move...
Are you the new listmom? sqb Hey gang, Im not naming names but Im feeling some heat when it's about time I enjoy a nice Sunday evening with my family - lets leave the past in the past and kill this thread. If you want to continue on an individual basis on this topic, then please email each other offlist. Best regards, Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hi Geoff, One does come to mind, it's the startup handler(s) of my splash stack, and they are broken down serially into 7 or 8 different handlers, each numbered sequentially with a handler name. And because I want to be able to read them one after the other, I ended up programming them serially. Some were as long as 50-60 lines, others shorter. Because they form the code of virtually all of my applications, I wanted them to be very easily read, and updated. This worked for me. May not have for you, I don't know. I doubt my brain can grasp thinking in bigger chunks..it's working overtime as it is! -Chipp Geoff Canyon wrote: Out of curiosity, do you have an example handy of a long handler that you think makes more sense to keep together than to break up? Or one that you think can't be broken up without significant effort to do it? When you think of a long handler, do you generally think of it as having a single identifiable task, or do you think of it as being several tasks performed in sequence in one handler? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/20/06, Geoff Canyon [EMAIL PROTECTED] wrote: Out of curiosity, do you have an example handy of a long handler that you think makes more sense to keep together than to break up? Or one that you think can't be broken up without significant effort to do it? When you think of a long handler, do you generally think of it as having a single identifiable task, or do you think of it as being several tasks performed in sequence in one handler? Obviously it's possible that you simply think in bigger chunks ;-) In my experience, it's probably due to never passing values by reference. If I am working on a routine that generates multiple variables, then acts on them, it is easier to keep it all together than to try and transfer more than one variable back forth between handlers functions. A separate function is great if it only has to return one variable, but as soon as it acts on more than one, I find it easier to leave that code as part of the main handler. Of course, if a segment of code is used by more than one handler, it's worth the effort to split it out, but otherwise, I'm not too fussed about keeping handlers small. Good commenting can overcome any problems interpreting it later :-) Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
This sounds like a bunch of small handlers masquerading as a large handler ;-) Nothing wrong with that, I just think it means that you're really on my side of the big/small question, except that you don't like the surplus of handler names it leads to. I can certainly agree with that. Every time I've ever advocated small routines, I've mentioned as one of the caveats that you end up with that many more handlers to keep track of. As you say, if the task is never called separately, and you break it out within the larger handler, and you document it, it's not that big a deal. I'd argue that if you've done all that you might as well break it out as a separate routine, but I think we've reached the pot-ay-tos, pot-ah-tos stage of the discussion. gc On Mar 20, 2006, at 1:38 AM, Chipp Walters wrote: Hi Geoff, One does come to mind, it's the startup handler(s) of my splash stack, and they are broken down serially into 7 or 8 different handlers, each numbered sequentially with a handler name. And because I want to be able to read them one after the other, I ended up programming them serially. Some were as long as 50-60 lines, others shorter. Because they form the code of virtually all of my applications, I wanted them to be very easily read, and updated. This worked for me. May not have for you, I don't know. I doubt my brain can grasp thinking in bigger chunks..it's working overtime as it is! -Chipp Geoff Canyon wrote: Out of curiosity, do you have an example handy of a long handler that you think makes more sense to keep together than to break up? Or one that you think can't be broken up without significant effort to do it? When you think of a long handler, do you generally think of it as having a single identifiable task, or do you think of it as being several tasks performed in sequence in one handler? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. On Mar 20, 2006, at 4:29 AM, Sarah Reichelt wrote: In my experience, it's probably due to never passing values by reference. If I am working on a routine that generates multiple variables, then acts on them, it is easier to keep it all together than to try and transfer more than one variable back forth between handlers functions. A separate function is great if it only has to return one variable, but as soon as it acts on more than one, I find it easier to leave that code as part of the main handler. Of course, if a segment of code is used by more than one handler, it's worth the effort to split it out, but otherwise, I'm not too fussed about keeping handlers small. Good commenting can overcome any problems interpreting it later :-) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
G'day Sarah, In my experience, it's probably due to never passing values by reference. I'm curious as to why you eschew passing by reference. If one needs to pass large variables, why incur the overhead of duplicating the value of the variable before passing it? And if a variable value needed at one level is derived from a routine nested several calls deep, simply passing the variable by reference through the nested calls is the simplest way to get the value back to the original caller. Case in point: An SDB record can be as large as the maximum amount of text one field can contain. If the syntax of the record retrieval command were getSDBRecord sdbBuffer,... instead of getSDBRecord @sdbBuffer,..., the command would have to create its own record buffer variable and then return a result which is copied into some other variable. By passing by reference, the two handlers (or as many handlers as needed) can work on a single copy of the data. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hi Geoff, Out of curiosity, do you have an example handy of a long handler that you think makes more sense to keep together than to break up? Or one that you think can't be broken up without significant effort to do it? on findSDBRecord @sdbBuffer,exactKey,fieldDelimiter,itemList,setPosition,searchForward,se archCriteria,cutoffKey,recordDelimiter,unlockRecord -- 28 Feb 04:RCC if ipcMode is not dc then -- dc = single user direct connection replace return with numToChar(29) in itemList replace return with numToChar(29) in searchCriteria requestSDBService sdbBuffer,find,packArguments(9,exactKey,fieldDelimiter,itemList,setPos ition,searchForward,searchCriteria,cutoffKey,recordDelimiter,unlockRecor d) get the result if not word 1 of it and setPosition then put word 4 of it into sdbPosition put it into sdbParameters return it else if invalidSDBClient() then return truereturnsdbMessage(sdbInvalidClientError,true) if offset(returnsdbDbIdreturn,return(the keys of indexList)return) = 0 then return truereturnsdbMessage(sdbDbIdError,true) if exactKey is empty then put true into exactKey put (fieldDelimiter is not empty) into retrieveData if recordDelimiter is not empty then put true into multipleRecords put false into unlockRecords put false into setPosition else put false into multipleRecords put (multipleRecords and not retrieveData) into countOnly if setPosition is empty or retrieveData then put true into setPosition if searchForward is empty then put true into searchForward put ((sdbWriteAccess is Shared) and (unlockRecord is true)) into unlockRecord put word 2 to 4 of sdbParameters into savedPosition put justifyString(word 1 of sdbBuffer,4) into theRecordType getSDBRecord sdbBuffer,exactKey,,,setPosition,retrieveData get the result put word 2 to -1 of line 1 of sdbBuffer into recordKey if word 1 of it or (((recordKey cutoffKey and searchForward) or (recordKey cutoffKey and not searchForward)) and cutoffKey is not empty) then put falsesavedPosition into sdbParameters put false0 0 0 into line 1 of it return it else if unlockRecord and sdbWriteAccess is Shared then deleteDbLock(word 4 of sdbParameters) if not retrieveData and not multipleRecords then put it into sdbParameters return it end if end if put word 4 of sdbParameters into oldPosition put empty into returnRecord put 0 into recordCount repeat put word 2 to -1 of line 1 of sdbBuffer into recordKey if (recordKey cutoffKey and searchForward) or (recordKey cutoffKey and not searchForward) then put false into word 1 of sdbParameters if countOnly then put empty into sdbBuffer return (word 1 to 3 of sdbParameters)recordCount else put theRecordTyperecordCountreturnreturnRecord into sdbBuffer return (word 1 to 3 of sdbParameters)0 end if end if delete line 1 of sdbBuffer if theSDBRecordMatches(sdbBuffer,fieldDelimiter,searchCriteria) then add 1 to recordCount repeat for each line itemNumber in itemList put sdbFieldNumber(itemNumber) into itemNumber if itemNumber = 0 then put recordKeyfieldBelimiter after returnRecord else put getItem(itemNumber,fieldDelimiter,sdbBuffer)fieldDelimiter after returnRecord end repeat if multipleRecords then put recordDelimiter after returnRecord else put theRecordTyperecordKeyreturnreturnRecord into sdbBuffer return (word 1 to 3 of sdbParameters) end if end if set cursor to busy if searchForward then if word 2 of sdbParameters word 3 of sdbParameters then put + into sdbBuffer getSDBRecord sdbBuffer,exactKey,,,true,retrieveData put the result into sdbParameters else put true into sdbParameters else if word 2 of sdbParameters 1 then put - into sdbBuffer getSDBRecord sdbBuffer,exactKey,,,true,retrieveData put the result into sdbParameters else put true into sdbParameters end if if word 1 of sdbParameters then put false into word 1 of sdbParameters put oldPosition into word 4 of sdbParameters if countOnly then put empty into sdbBuffer return (word 1 to 3 of sdbParameters)recordCount else put theRecordTyperecordCountreturnreturnRecord into sdbBuffer return (word 1 to 3 of sdbParameters)0 end if else if not setPosition then put oldPosition into word 4 of sdbParameters end repeat end if end findSDBRecord Note: stack local variables and constant declarations excluded. application requirement: calling syntax at server and client apps must be identical...
Re: Making the move...
On 3/20/06 9:28 AM, Rob Cozens [EMAIL PROTECTED] wrote: on mouseTrapOn -- 3 Mar 04:RCC insert the script of field Mouse Trap of card 1 of stack Serendipity_Library.rev into front end mouseTrapOn I suppose you also have a SerendipityDo_Library.rev for those calls that need extra hold, eh? Jim Ault Las Vegas ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Moi: if itemNumber = 0 then put recordKeyfieldBelimiter after returnRecord Thanks for getting me to revisit the handler, Geoff: fieldBelimiter was a bug waiting to bite me. Rob Cozens CCW, Serendipity Software Company And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee. from The Triple Foole by John Donne (1572-1631) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hi Jim,
I suppose you also have a
SerendipityDo_Library.rev
It's still a work in process; but will be released as
SerendipityDoDa_Library.rev so folks won't think it's
SerendipityDoDo. :{`)
Rob Cozens
CCW, Serendipity Software Company
And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee.
from The Triple Foole by John Donne (1572-1631)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Rob- Monday, March 20, 2006, 10:04:01 AM, you wrote: Thanks for getting me to revisit the handler, Geoff: fieldBelimiter was a bug waiting to bite me. ...and that's why I'm such a stickler for declaring variables. If the compiler can find your bugs for you, why not let it do the work? -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 14, 2006, at 6:40 AM, [EMAIL PROTECTED] wrote: Josh, Very strong statements. Wow! If I may ask for further clarification... I have two questions I'd love you expound upon. 1) RealBasic -- that's the main rival, as I see it. I haven't written big enough apps to test, but it seem that the compiler is pretty fast. I wonder how they compare in development and upkeep of for database projects. What are your thoughts about the 2 development environments? We developed a product in RealBasic a few years ago and never released it- (Director was not OS X compatible yet and so not an option). At that time (several years ago) we found the compiler slow and the general performance atrocious (rollover graphics working intermittently, slowly, sticking on over or down states, QT movies stuttering. Of course a lot may have changed since then... 2) Revolution vs Ruby on Rails? You mean to say you use Revolution to write browser enabled web-apps? Something I could access with Firefox? If so, I'd love to hear more. Read Richard Gaskin's article about Beyond the Browser. http:// www.fourthworld.com/embassy/articles/netapps.html Everyone is going nuts over Web 2.0, AJAX, Ruby on Rails... sure, for many applications (like, a website for example!) running something in a browser makes sense. For any serious business or media application, all the days of trying to make Javascript work across browsers, degrade gracefully, etc. can be better spent making the app better! Just like you have to download iTunes, RealPlayer, Google Earth, etc., an independent executable that communicates with a remote shared database makes way more sense to me than trying to force a browser to do more than pictures and text. The exception is Flash, an amazing technology that runs in a browser, but sadly, the dev environment seems more suited for masochists than people who just want the job done... before lunch. Just my .03 (inflation) Thanks again for you very insightful comments. I really appreciate them. Michael ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Marielle, I believe this response to Chipp is a unfair. The post you cite regarding Jerry was apologized for almost immediately after he realized that he sent it to the list and not to Jerry personally. And I seem to recall Jerry being nearly abusive in the posts sent around that time. I don't have the time at present to go google pipermail to cite each and every post, but you might wish to do so to revisit the issue in its larger context. As for Richmond, my impression (for what very little it is possibly worth) is that, while he is perhaps an individual of passion and industriousness, he can also be a tad on the nasty side (private and public mails) and drove me nearly stark raving batty with his continued whining about why he couldn't have Rev for free while the rest of us were paying as well as we could to update our licenses and do our part to help the company maintain revenue needed to fix whatever it was that any of us might have been bitching about to get fixed. Teachers get paid for their teaching assignments (not alot, I'll concede). Mightn't all students all similarly insist that 'information wants to be free' and that teachers should just give their time away and beg on the streets for daily bread? Outside of Socrates (whose wife was continually begging him to go build walls and the like), I suspect that there are remarkably few educators who would apply to themselves the sentiment that they seem to demand of software developers. Judy ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 14, 2006, at 3:17 PM, [EMAIL PROTECTED] wrote: So I anticipate that the web apps would be VERY simple, and it might even be possible to push the date into something like PHP- Fusion or Joomla! Joomla = NO WordPress = YES e107 = YES : ) from one who has done way too much experimentation with open source CMS apps! ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 19, 2006, at 12:55 PM, Mark Wieder wrote: It's probably my forth background, but I'm mildly allergic to routines that don't fit in their entirety onto my screen. -- -Mark Wieder [EMAIL PROTECTED] Ah, I just realized why I'm writing overly complex handlers and not using functions... a 30 Cinema Display :-( Kachoo! ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
OMG, Judy, two things we can agree on in, what?, less than a month? Perhaps the end of the cycle is imminent! :-) I spent two years once trying to sell a product into the education market. (I use quotation marks because in my experience -- which may well have been unique for all I know -- there is no such thing as a market called education.) Here's what I ran into (enough years ago that some of it may no longer be valid and it specifically applies to K-12, not secondary): 1. The decision-maker is often hard to find. This was a real deal-blocker for us. I'm not kidding. In one case, we found out that the key decision maker in determing what software a school district (a large one, at that) would buy was the nephew of the superintendent who worked as an outside consultant. He wasn't on an org chart and we could not make a direct presentation to him. That was the extreme but it was only a matter of degree. 2. Educators often cried poor-mouth, seeking deep, deep discounts that would have resulted in our inability to stay in business but then they also wanted reliable tech support (including pre-sale) and training. 3. Too often, educators felt justified taking our proprietary software and duplicating it for their fellow educators, on the same basis as #2, i.e., they were under-funded and under-paid. Now I'm not going to argue that educators are adequately compensated let alone overpaid. And I know that in the U.S. at least the priority we place on education in our budgets is horrific in contrast to the lip service we pay to the importance of education in our society. But even programmers have to eat (though they seem able to subsist of Jolt and Twinkies for extended periods of time, with the odd pizza tossed in for good measure.) But what does seem to me to be the case is that, as I think I hear you saying, educators seem (in general) to be OK with taking advantage of people who supply software technology to make their jobs easier but are not OK with others wishing to take advantage of their good nature as altruistic participants in the social discourse. And at the end, I just find this very interesting, not necessariiy negative or problematic. On 3/20/06, Judy Perry [EMAIL PROTECTED] wrote: I suspect that there are remarkably few educators who would apply to themselves the sentiment that they seem to demand of software developers. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/21/06, Rob Cozens [EMAIL PROTECTED] wrote: G'day Sarah, In my experience, it's probably due to never passing values by reference. I'm curious as to why you eschew passing by reference. If one needs to pass large variables, why incur the overhead of duplicating the value of the variable before passing it? And if a variable value needed at one level is derived from a routine nested several calls deep, simply passing the variable by reference through the nested calls is the simplest way to get the value back to the original caller. It's not a philosophy, more ignorance :-) I haven't ever really tested it and I have an instinctive feeling that functions should be self-sufficient and shouldn't change anything outside them. Maybe it will suit me better in some circumstances. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Well I think you are right - there would be better ways to split out segments of the script, and if I find more than one routine neededing to do the same things, I go to the effort of doing it. However at the moment, I am mainly concerned with converting HyperCard scripts to Rev, and so I like to change as little as possible, to make sure I don't mess anything up. Cheers, Sarah On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote: Do you have an example? I agree that if you end up passing in a handful of arguments by reference, you haven't accomplished much by breaking out the routine. The question is if there isn't a better way to slice the routine, where that wouldn't be necessary. On Mar 20, 2006, at 4:29 AM, Sarah Reichelt wrote: In my experience, it's probably due to never passing values by reference. If I am working on a routine that generates multiple variables, then acts on them, it is easier to keep it all together than to try and transfer more than one variable back forth between handlers functions. A separate function is great if it only has to return one variable, but as soon as it acts on more than one, I find it easier to leave that code as part of the main handler. Of course, if a segment of code is used by more than one handler, it's worth the effort to split it out, but otherwise, I'm not too fussed about keeping handlers small. Good commenting can overcome any problems interpreting it later :-) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
I think the point is that when a variable is passed to a function/ handler 'normally', the data in it is duplicated, and if the data is big, this is not as efficient as passing it by reference - obviously, if you need to change the data in the called function/handler, this may have unwanted side-effects, in which case passing it normally is going to be better. Mark On 21 Mar 2006, at 02:20, Sarah Reichelt wrote: On 3/21/06, Rob Cozens [EMAIL PROTECTED] wrote: G'day Sarah, In my experience, it's probably due to never passing values by reference. I'm curious as to why you eschew passing by reference. If one needs to pass large variables, why incur the overhead of duplicating the value of the variable before passing it? And if a variable value needed at one level is derived from a routine nested several calls deep, simply passing the variable by reference through the nested calls is the simplest way to get the value back to the original caller. It's not a philosophy, more ignorance :-) I haven't ever really tested it and I have an instinctive feeling that functions should be self-sufficient and shouldn't change anything outside them. Maybe it will suit me better in some circumstances. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 20, 2006, at 9:01 PM, Mark Smith wrote: I think the point is that when a variable is passed to a function/ handler 'normally', the data in it is duplicated, and if the data is big, this is not as efficient as passing it by reference - obviously, if you need to change the data in the called function/ handler, this may have unwanted side-effects, in which case passing it normally is going to be better. The problem you raise here is handled in more traditional languages by declaring the reference to be constant. It strikes me that it would not be a big change to expand the use of the constant keyword. Then in situations such as Sarah was talking about the handler/function would be declared as not changing the referred to variable, something like on myHandler constant @pByReferenceParameter -- following then should cause compiler error add 1 to @pByReferenceParameter end myHandler There is, of course, another use for references besides the efficiency of not having to copy large data structures: returning more than one value. This use doesn't suffer from the concern Sarah raises about having external effects as, when used this way, the parameter passed in should be empty. There isn't, of course, any guarantee of this other than the caller being careful and writer of the called function being careful to document that the parameter is used for output only. Spence James P. Spencer Rochester, MN [EMAIL PROTECTED] Badges?? We don't need no stinkin badges! ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Ever the metaphorical thinker, this reminds me of good gun safety practices (aka ways NOT to shoot yourself in the foot) - it's all in knowing how to control a powerful tool. Phil Davis (meant in a lighthearted way and limited strictly to the parallel observed - not intended to engender discussion/debate about guns) Mark Smith wrote: I think the point is that when a variable is passed to a function/ handler 'normally', the data in it is duplicated, and if the data is big, this is not as efficient as passing it by reference - obviously, if you need to change the data in the called function/handler, this may have unwanted side-effects, in which case passing it normally is going to be better. Mark On 21 Mar 2006, at 02:20, Sarah Reichelt wrote: On 3/21/06, Rob Cozens [EMAIL PROTECTED] wrote: G'day Sarah, In my experience, it's probably due to never passing values by reference. I'm curious as to why you eschew passing by reference. If one needs to pass large variables, why incur the overhead of duplicating the value of the variable before passing it? And if a variable value needed at one level is derived from a routine nested several calls deep, simply passing the variable by reference through the nested calls is the simplest way to get the value back to the original caller. It's not a philosophy, more ignorance :-) I haven't ever really tested it and I have an instinctive feeling that functions should be self-sufficient and shouldn't change anything outside them. Maybe it will suit me better in some circumstances. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Holy Batcrap, Dan! Like, is it a full moon? Are the planets in alignment?? Did I miss a supernova somewhere obvious??? :-) You know, I have always held that rumours of our supposedly concrete disagreement status are greatly exaggerated. Yeah, I've seen something very like what you are talking about (Point No. 1, that is; probably the others as well). Something very similar is why, although funding has been approved, my FrankenLab won't be fixed anytime soon, if at all. As for your points 2 3 (which to me seem to be the samething), I've seen that too. While in the midst of a rather painful msidt (see how it relates to midst??? msidt = master of science in instructional design and technology; sorry for the pun; it was a really dreadful program), we students were in the midst of this small (as in, *really* small) unit on copyrighted materials and fair use in the classroom, and a rather vocal seeming majority of my fellow students stridently held that their mission to educate trumped basic property rights. When I objected, I was basically called a pie in the sky and ivory tower higher-ed type. And I'll bet their software budget is bigger than mine. Judy On Mon, 20 Mar 2006, Dan Shafer wrote: OMG, Judy, two things we can agree on in, what?, less than a month? Perhaps the end of the cycle is imminent! :-) I spent two years once trying to sell a product into the education market. (I use quotation marks because in my experience -- which may well have been unique for all I know -- there is no such thing as a market called education.) Here's what I ran into (enough years ago that some of it may no longer be valid and it specifically applies to K-12, not secondary): 1. The decision-maker is often hard to find. This was a real deal-blocker for us. I'm not kidding. In one case, we found out that the key decision maker in determing what software a school district (a large one, at that) would buy was the nephew of the superintendent who worked as an outside consultant. He wasn't on an org chart and we could not make a direct presentation to him. That was the extreme but it was only a matter of degree. 2. Educators often cried poor-mouth, seeking deep, deep discounts that would have resulted in our inability to stay in business but then they also wanted reliable tech support (including pre-sale) and training. 3. Too often, educators felt justified taking our proprietary software and duplicating it for their fellow educators, on the same basis as #2, i.e., they were under-funded and under-paid. Now I'm not going to argue that educators are adequately compensated let alone overpaid. And I know that in the U.S. at least the priority we place on education in our budgets is horrific in contrast to the lip service we pay to the importance of education in our society. But even programmers have to eat (though they seem able to subsist of Jolt and Twinkies for extended periods of time, with the odd pizza tossed in for good measure.) But what does seem to me to be the case is that, as I think I hear you saying, educators seem (in general) to be OK with taking advantage of people who supply software technology to make their jobs easier but are not OK with others wishing to take advantage of their good nature as altruistic participants in the social discourse. And at the end, I just find this very interesting, not necessariiy negative or problematic. On 3/20/06, Judy Perry [EMAIL PROTECTED] wrote: I suspect that there are remarkably few educators who would apply to themselves the sentiment that they seem to demand of software developers. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Geoff- Saturday, March 18, 2006, 1:24:50 PM, you wrote: I've never seen a hundred-line routine that wouldn't be better as five twenty-line routines, each of which could be documented with a line of code. Perhaps even ten ten-line routines. It's probably my forth background, but I'm mildly allergic to routines that don't fit in their entirety onto my screen. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
If you aren't happy with the tool, then just don't use it. It's that simple. It is not very wise to say so. If all dissatisfied persons on this list followed your advice, in the present context, this could cost runrev very many clients. My personal view on this is that it is better to express the reasons for dissatisfaction so that the problems can be resolved. What I have seen on this list is that you just want to get rid of the persons who tell you there is a problem... and keep your problem. I am interested in using the excellent product that revolution is. I am not interested to have to accept to deal with problems like the present ones for the months to come for the priviledge to use it. For the record, Richmond was banished. He was brought back only because I did intercede for him. The reason he ended up using cursed language is because of his growing frustration at being asked to shut it up on his discourse on open source. Honestly, your very biased and overtly hostile email is an invitation for insults. A proof of this is that you already received emails back when you wrote a similar email to a user who had the very stupid idea to do the same thing as me, express a criticism. http://mail.runrev.com/pipermail/use-revolution/2005-December/ 071769.html Why isn't Rev more popular? Jerry Saperstein runrev at civildiscovery.com Mon Dec 5 20:30:16 CST 2005 Criticism of Revolution generally apparently is generally disapproved of here. I've seen a number of valid criticisms dismissed in the same way as yours have been. And what argument did you use to dismiss her claim... nothing but Innuendo and defamation, something *far too frequent* on this list. http://thread.gmane.org/gmane.comp.ide.revolution.user/71131 From: Chipp Walters [EMAIL PROTECTED] Subject: Re: Why isn't Rev more popular? Newsgroups: gmane.comp.ide.revolution.user Date: 2005-12-06 04:59:20 GMT (14 weeks, 5 days, 16 hours and 35 minutes ago) You wouldn't be the Jerry Saperstein of Font Bank fame who was accussed back in the 90's of stealing clipart intellectual property and reselling it...would you? If so, how'd that turn out? The fact that you discredited her in this unacceptable ways probably didn't help. She ended up insulting you. I won't insult you. But being in the position Richmond was put or Jerry was put, I understand their reaction. I don't approve it. But I understand how they came to explode. They did it because some not so acceptable means were used to discredit them and there was nothing they could say anymore to have the truth restored. Fortunately for me, it is probably less easy to discredit the person who contributed this to the community: http://revolution.widged.com/wiki/tiki-index.php? page=TutorialsTeacherManual http://revolution.widged.com/stacks/ http://codes.widged.com/ I am a defender of runrev. And it is BECAUSE I am a defender of runrev that I do take the time to speak out and denounce problems that contribute to keep persons AWAY from this excellent product. I don't know what game you play Chipp, Dan, Richard, but it really looks like you are trying to prevent the members of the non profit community to express their views and describe their needs on this list. Anytime they do, they are discredited. Richard said he was sorry to see freeGui not more popular. Apparently, he was not sorry defaming the freeGui project leader on the metacard list: http://mail.runrev.com/pipermail/metacard/2006-February/009068.html While it's hard to find a post from you regarding Rev in any forum which doesn't turn it into an opportunity to express your negative opinions about the product, in this case it seems Kevin chose to finish a thread that was started here by writing to an entirely different list. My apologies for thinking that this latest post from you was like the dozens before it. For the record, Richmond didn't hack to the RR website. I am completely fed up to see the likes of you transform the truth on this list and discredit persons who have been deprived from the right to defend themselves. No hack was required to see the 2.7 announce, a simple search on google was enough. Richmond lacked of judgement, I agree. But he clearly didn't mean to do any harm. If he could access to this page, the error was the one of runrev's not his (the page, was NOT password protected and if you reached it via google, you had no way to know you were accessing information you were not supposed to access). The fact that he emailed a copy of the 2.7 announce on the list didn't justify to see him banish. Anybody else would have done so, there would have been no consequences (yes, I know, most persons wouldn't have done so, but that's a different issue). For the record, Xavier doesn't really have the opportunity to defend himself on this list because Kevin recently sent him an email to tell Xavier that if
Re: Making the move...
Yep, I've heard that before, but frankly, for me, I'd rather keep it all in one, unless there's a really good reason to separate into multiple handlers (as in creating more reusability). I find it much easier to debug code I've written this way than hunting through the message path for the 15 or so functions/handlers I've written trying to make things 'more simple.' Just a difference in coding style. In fact, typically I'll write code procedurally in a longer handler, then only break it up if/when I know I need to do part of the same thing again. Like most of us, I'd rather not code twice. Even though, I've got libraries with over 50 handlers/functions. -Chipp Mark Wieder wrote: Geoff- Saturday, March 18, 2006, 1:24:50 PM, you wrote: I've never seen a hundred-line routine that wouldn't be better as five twenty-line routines, each of which could be documented with a line of code. Perhaps even ten ten-line routines. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Marielle, Notwithstanding your earlier private unsolicited (and unresponded to) rants to me (and others) on why you hate Revolution, it is obvious you like to have the last...oh 1000 words. Bravo. -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Marielle, I really don't get how anyone thinks that genuine and justified criticism of Revolution is somehow not tolerated on this list. On 19 Mar 2006, at 22:17, Marelle Lange wrote: What I have seen on this list is that you just want to get rid of the persons who tell you there is a problem... and keep your problem. I am interested in using the excellent product that revolution is. I am not interested to have to accept to deal with problems like the present ones for the months to come for the priviledge to use it. People do almost nothing other than discuss problems on this list - some are problems of comprehension or experience, some are problems with the docs, some are bugs...they get discussed quite reasonably, whatever they are...but then http://mail.runrev.com/pipermail/use-revolution/2005-December/ 071769.html Why isn't Rev more popular? Jerry Saperstein runrev at civildiscovery.com Mon Dec 5 20:30:16 CST 2005 Criticism of Revolution generally apparently is generally disapproved of here. I've seen a number of valid criticisms dismissed in the same way as yours have been. And what argument did you use to dismiss her claim... nothing but Innuendo and defamation, something *far too frequent* on this list. http://thread.gmane.org/gmane.comp.ide.revolution.user/71131 From: Chipp Walters [EMAIL PROTECTED] Subject: Re: Why isn't Rev more popular? Newsgroups: gmane.comp.ide.revolution.user Date: 2005-12-06 04:59:20 GMT (14 weeks, 5 days, 16 hours and 35 minutes ago) You wouldn't be the Jerry Saperstein of Font Bank fame who was accussed back in the 90's of stealing clipart intellectual property and reselling it...would you? If so, how'd that turn out? The fact that you discredited her in this unacceptable ways probably didn't help. She ended up insulting you. I won't insult you. But being in the position Richmond was put or Jerry was put, I understand their reaction. I don't approve it. But I understand how they came to explode. They did it because some not so acceptable means were used to discredit them and there was nothing they could say anymore to have the truth restored. Fortunately for me, it is probably less easy to discredit the person who contributed this to the community: http://revolution.widged.com/wiki/tiki-index.php? page=TutorialsTeacherManual http://revolution.widged.com/stacks/ http://codes.widged.com/ I just reviewed the Jerry Saperstein thread, and I think the same thing I thought at the time : Jerry came on with one of the most obvious pieces of transparently provocative trollery I've seen. Her assertion was that Revolution was 'unusable for business apps' - a term never explained, despite many requests for clarification, and no examples of problems she had encountered were ever forthcoming. She then insinuated, fairly clearly, that claims made by list members as to the fruits of their labours in Revolution were lies. It's not surprising she got short shrift. I am a defender of runrev. And it is BECAUSE I am a defender of runrev that I do take the time to speak out and denounce problems that contribute to keep persons AWAY from this excellent product. I don't know what game you play Chipp, Dan, Richard, but it really looks like you are trying to prevent the members of the non profit community to express their views and describe their needs on this list. Anytime they do, they are discredited. I am a non profit user of Rev...I simply don't understand how Chipp, Dan and Richard or anyone else are supposed to be discrediting anyone, or preventing anyone from describing their needs. Dan's email on Ruby was WOW. Very kindly, as usual, he went to check up some very popular resource out there, and came back to tell us that it was not worth checking up. Ruby was *far too complex*, *nothing useful could be done with it*, *revolution could be used the same way Ruby is*. But know that I am *very* uncomfortable with your practices within *this* community, where you too often take advantage of the credulity of the users. Then I discoverd Ruby on Rails. For me -- and certainly there are other frameworks out there that others may favor -- no other Web app development approach comes even close. - Dan Shafer ? I'm really in no position to comment on Richmond or Xaviers differences with RunRev, so I won't. Honestly, I'm wondering if you and I are reading the same list! Baffled, Mark ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Making the move...
Hey gang, Im not naming names but Im feeling some heat when it's about time I enjoy a nice Sunday evening with my family - lets leave the past in the past and kill this thread. If you want to continue on an individual basis on this topic, then please email each other offlist. Best regards, Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Making the move...
Hi Chipp, Yes, this is a very relevant list, though some things have changed at bit. He gave 3 reasons for this: 1) The culture. Great software is typically created by a small group of only a few developers-- not the Japanese way of throwing manpower at a problem. Furthurmore, typcially good developers are not very social and can be obstinate (duh!), which again flys against the culture. And, the program all night when on a roll, then sleep all day type would never fly in a Japanese corporation. There is a growing studio mentality in Japan and also, the weirdness that is family owned business. A few years ago, a merger between Sega and Bandai failed because Bandai is a family run business, and Sega is more mainstream (actually they have a more hardcore, no prisoners culture comparable to Oracle). What Chipp is referring to above is interesting because, it rarely happens in the office but it can happen in incremental improvements happening on the floor -- where suits rarely go. A surprising amount of those incremental improvemetns come from the floor. 2) It is very difficult for startup companies to begin in Japan. There are huge incorporation fees, plus it's almost impossible to go public, so it's difficult to find investors, Because the 'equity' of a software startup is not 'tangible', it's very difficult to get banks to become involved, and a good banking relationship is very important to startups. This has gotten better in some ways, worse in others. When the Japanese bubble economy popped, quite a few banks simply closed, merged or were bought out. While there is now a VC climate in Japan, I don't think its really made up for the hard times. At one time simple incorporation stamp cost you $10K. Now it is possible to get by with much less, or create a foreign subsidiary without the huge paid in capital requirements of yore. 3) Lastly, the best computer languages were based in English, and very different from the way Japanese read and write. And in addition, the computer industry was dominated by the NEC 9800 platform, which was close but not quite the same as the AT architecture here - dominated as in Microsoft made versions of DOS and Windows for it. Id say this is one of the reasons why the Mac maintained a foothold longer in Japan than in other places - the mainstream x86 architecture had to compete with the NEC platform. I imagine much of this has changed in the past 10 years or so since we last talked, but I still believe many of his concerns have some validity. Of course, as recently as a couple of years ago, I toured a new CG Manga studio where people slept on the floor under the desks in makeshift tent-beds and generally had a more 'western' feel like many game studios do today. Yes, and I think there is a certain infectiousness to this as well, esp in creative industries. Of course, as they say, the proof is in the pudding. And, we've yet to see any big mainstream programs come out of Japan. But, there are some. I believe Shade 3D is a Japanese program (Lynn, you may know about this?). Yes, and while it is a great product, the mid-market (and up) marketspace for 3D applications, as a vertical market, has been in a total bloodbath for years -- and its gotten much worse with the acquisition of Alias. Shade is an excellent example. Its quite good, esp if you come from a CAD or architecture background. E-frontier, makers of Shade, acquired Curious Labs (makers of Poser) now little over two years ago, and they are making some of those famous Japanese improvements to Shade to adapt to the US market. They also have a good US staff that really know the 3D industry here. Another piece of software that is Japanese is --- the Ruby language. My first company did a lot of work with early Japanese game companies (back in the Super Nintendo days) and while the underlying software was incredibly fast (written mostly in assembly, with very little of that wimpy C or C++ stuff ;-)) - it seemed that almost all the games were exactly the same, except for some funny graphics and backstory. Best regards, Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Lynn- Saturday, March 18, 2006, 6:33:05 AM, you wrote: Another piece of software that is Japanese is --- the Ruby language. Ah... you beat me to it. I was going to chime in about Ruby. Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd ...love the new sig... -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hi Mark, Any chance to see you post the relevant code on this list? I read the ECMI document but don't remember the part describing conventions for describing the API in a way similar to the one outlined in the javadoc. Is it possible for you to cut paste the relevant excerpt on this list... or give pointers to page numbers if too long? Many thanks, Marielle Marielle Lange (PhD), Psycholinguist Alternative emails: [EMAIL PROTECTED], Homepage http://homepages.widged.com/mlange/ Easy access to lexical databaseshttp:// lexicall.widged.com/ Supporting Education Technologists http:// revolution.widged.com/wiki/ ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On Mar 17, 2006, at 1:20 PM, Mark Wieder wrote: ...sure there is. You have to roll your own, but it's not that much transcript code. My libraries generate their own documentation through a javadoc-like mechanism. Check out, for example, my ArchiveSearch plugin on revonline and open the libDispatcher library. Click on the API button. I strive to make my functions/handlers small enough that a single line of documentation is sufficient. Actually size isn't so much of a factor as the single-purpose aspect. If a function or handler has a single purpose, generally it can be described in a single sentence. Then I include that line as a comment after the definition: on setupHOOTClasses -- creates an array (sMessageArray) of the messages each class can receive on startHOOT -- initializes HOOT and sets it as a front script Then there are the handlers that are self-explanatory: on stopHOOT on hideNavigator I've never seen a hundred-line routine that wouldn't be better as five twenty-line routines, each of which could be documented with a line of code. Perhaps even ten ten-line routines. regards, gc ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/18/06 2:00 PM, Marielle Lange [EMAIL PROTECTED] wrote: Hi Mark, Any chance to see you post the relevant code on this list? I read the ECMI document but don't remember the part describing conventions for describing the API in a way similar to the one outlined in the javadoc. It's not similar to javadoc, but the method for describing the API to the handlers in a library at documented in the uRIP[interface] property of the ECMI specifications. Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hey Dan, thanks for the quick note. I think I get now. 8080 is already open. Launch this and the metacard stack listens without changing any control panel stuff. Just tried the following: Safari http://localhost:8080/~jault/ === stack running as an app (dbl clk) no problems Explorer from a Windows XP computer on my local network Firewall OFF http://192.168.15.100:8080/~jault/ === stack running as an app (dbl clk) CRASHED metacard Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x From FireFox on the same Mac http://192.168.15.100:8080/~jault/ === CRASHED metacard EXC_BAD_ACCESS (0x0001) KERN_PROTECTION_FAILURE (0x0002) at 0x From Safari on the same Mac http://192.168.15.100:8080/~jault/ === CRASHED metacard Safari can¹t open the page ³http://192.168.15.100:8080/~jault/². The error was: ³lost network connection² (NSURLErrorDomain:-1005) now I am confused. Jim Ault Las Vegas On 3/16/06 11:48 PM, Dan Shafer [EMAIL PROTECTED] wrote: Well, at least from the mc stack, you just run it and it seems to intercept the call on the designated port. You can manually change the port in the launch stack as well. PRetty cool stuff. On 3/16/06, Jim Ault [EMAIL PROTECTED] wrote: On 3/16/06 6:54 PM, Richard Gaskin [EMAIL PROTECTED] wrote: The default port in mchttpd is 8080 -- on my Mac I use: http://localhost:8080/ Woiks very good... cool. Is there a tutorial about how to put this in action on my G4 that has a static IP? I know that Apache would be the default receiver of 8080 traffic and I am definitely not a config-mechanic. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
The missing link is the killer app made with it. RoR was virtually unheard of before BaseCamp took off, showing the world how powerful and flexible RoR is. If we had an app of similar scope and appeal I have no doubt that as long as the engine is free for such uses and the scripts are open source it would attract considerable attention. The possibilities have been there for about 10 years. So why is it that Java is now in position 1 and Ruby in position 22 of the most popular programming languages and that none of xtalk, hypertalk, transcript is mentioned anwhere in the 100 most popular ones (though RealBasic and SmallTalk are)? http://www.tiobe.com/tpci.htm Yes, runrev product is great in the sense that it is easier to use by beginner programmers than many other things on the market. It is also great in the sense that it let advanced programmers do more in less time (but not necessarily *better*). It is also great in the sense that it let you do out of the box what would take hours if not days to set up in other environments. On this list, all discussions always come back to the same thing. This product is so great, this is so evident that everybody should adopt it... Runrev too has appeared to think that to have a great product is enough and they had to do nothing but let it sell itself. I am afraid, to have a great product is not enough. What you get with Java, Ruby, Ajax that you don't get with runrev is the following. 1) Re-usable LIBRARIES. Honestly what I have read recently on how revolution is so much superior to Director or Java is just a *BIG* joke. Agreed, revolution let you write stuff rapidly. But you have to write the same stuff again and again and again and again. But what java does is let you write it ONCE and REUSE it again and again and again. 2) Rich and easy to access documentation If you want to use a java library written by somebody else, simple, you get access to the API online and you know what method to call and how. You don't need to know *anything* about the inner workings of the library. Why is it? Because some some conventions have been created which let you comment your script in a very efficient way, where the API doc can be automatically generated from these comments. http://java.sun.com/j2se/javadoc/. There is *NOTHING* even close to this in revolution. Here, if you want to find your way through revolution it is by checking up the list as much as you can and post your questions on the list (which is an important problem for non English speaking persons). These nice little chats on the list are without doubt helping both the sender and the receiver feel very good about themselves, so priviledged to be in such a great community. Let's face it. This way of doing is plain inefficient compared to the way of doing in ruby or java communities. 3) Member's sense of investment in making their work freely available Yes, you can do fantastic stuff with revolution. But you have to start from zero and do everything by yourself. Because of all the effort, it is only worth it if you plan to sell your application to a small numbers of high-paying clients. So Richard, why is it that sourceforge project you are admin of is still empty? It was registered in 2001. http://sourceforge.net/projects/opn-repository A project to create a publicly accessible library of handlers for the xTalk family of languages. The immediate aim of this project is to create a robust library of handlers for the cross platform Metacard/RunRev xTalk family of products. I had a chance to see David's (Bovil) library of handlers: Very impressive. So, Lynch, if you have written such nice and reusable libraries for providing better table objects, why not share it with others? Maybe then, rather than have each one of us repeat your work, we may be able to start, collaboratively, construct tools of this quality: http://jcharts.sourceforge.net/samples/bar.html http://big.faceless.org/products/graph/index.jsp http://www.jfree.org/jfreechart/samples.php http://www.eteks.com/jeks/index.html http://www.thechiselgroup.org/projects 4) Structure that encourages and facilitates collaboration You can, in fact turn your work into reusable libraries, with a bit of experience in writing such stacks. People like Eric, Scott, and many others have very generously contributed high quality demo stacks, but the number of libraries available is just ridiculous compared to the ones on rubyforge/sourceforge. In sharp contrast with the ruby and java community, these libraries are not shared, there is nothing like rubyforge or sourceforge where you can easily provide information about your project and receive feedback on them. There is nothing like rubyforge or sourceforge where you can get to know of the existing projects and get to propose your collaboration. On top, though it is possible to write
Re: Making the move...
Marielle- Friday, March 17, 2006, 4:44:16 AM, you wrote: many Japanese management concepts such as Total Quality Control, Quality Control circles, small group activities, labor relations. Key elements of Kaizen are quality, effort, involvement of all employees, willingness to change, and communication. Having been involved with Total Quality initiatives, Quality Control Circles, etc, on this side of the pond I can say from experience that they are doomed to failure because of underlying cultural differences. Labor and social relationships are not structured in western societies to provide the level of trust and support required to allow them to be effective. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Making the move...
many Japanese management concepts such as Total Quality Control, Quality Control circles, small group activities, labor relations. Key elements of Kaizen are quality, effort, involvement of all employees, willingness to change, and communication. Having been involved with Total Quality initiatives, Quality Control Circles, etc, on this side of the pond I can say from experience that they are doomed to failure because of underlying cultural differences. Labor and social relationships are not structured in western societies to provide the level of trust and support required to allow them to be effective. Putting on my Proactive (http://www.proactive-intl.com) hat here on one of my favorite topics :-) Ill preface this by saying I lived in Japan for six years, have an office in Japan, Japanese spouse and bi-lingual family household. We have a good mix of Japanese staff. My kid has been cleaning my clock in spoken and written Japanese for years :-( I think almost all Japanese initiatives fail in the US for the same reason why many foreign endeavors don't make it in Japan - they werent adapted into processes towards a specific goal. And they apply differently in different industries, because there is a different mindset by industry - the automobile industry vs software is a perfect one. Total Quality Management didn't originate in Japan, but it is worshipped there. Japanese society is built around cooperation, unity, and fair treatment within the group - and you disappoint and fail the group if your product doesn't improve. It doesn't nourish creativity however, though the government has taken steps in their education system to help rectify that. There are some very good software products from Japan, but it isnt a culture that nurtures a maverick mentality that can result in lots of super programmers. You could point to console games as an industry dominated by the Japanese, but I think if you really looked at the way most of those games are structured (and that they license a lot of foreign 3D technology), you would be less impressed. But to go back to the point - adaptions Ive seen have been terrible - either self defeating or utterly silly. I think there are quality measures that can be gleaned and adapted to a certain point, with good results. Its just extremely rare. Best regards, Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Marielle wrote: What you get with Java, Ruby, Ajax that you don't get with runrev is the following. 1) Re-usable LIBRARIES. Honestly what I have read recently on how revolution is so much superior to Director or Java is just a *BIG* joke. Agreed, revolution let you write stuff rapidly. But you have to write the same stuff again and again and again and again. But what java does is let you write it ONCE and REUSE it again and again and again. Coding for reuse is a choice. There's a lot of Java out there that can barely be used, let alone reused. :) I rarely write the same routine in Transcript more than once, and every app I write is completed with considerably higher ROI than the last because of the ease of reusing code libraries. In my most recent project I would estimate that some 70% of the code base is in reusable libraries. There's even a Scripter's Scrapbook that Hugh Senior wrote in Rev to encourage even greater code reuse (with a jaw-droppingly complete feature set) at http://www.flexiblelearning.com/ssbk.htm. Stephen McConnell's Code Complete 2 offers a great insight into coding for reuse (among many other things), and just about anything from him is chock full o' good ideas. I've touched on reuse in my presentations at Rev conferences, and it would probably be useful to also address this in greater depth at revJournal. In the meantime, Extending the Runtime Revolution Message Path at http://www.fourthworld.com/embassy/articles/revolution_message_path.html introduces the mechanics of implementing libraries, and my Handy Handlers series at http://www.revjournal.com/tutorials/index.html discusses the style side of crafting handlers with an emphasis on generalized reuse. It should be noted that while the specifics of coding for reuse in Transcript often rely on mechanisms unique to the language, those mechanisms are simple to work with (e.g. start using libMyStuff) and the patterns governing reuse are pretty much the same as for other procedural languages (error-checking params, conscious source-to-dest param order, useful defaults for optional params, etc.). Any developer thinking ahead and exercising a little self-discipline can get the same level of benefit of code reuse in Transcript as in just about any procedural language, arguably more so in many cases given Transcript's self-documenting nature and the simplicity of using library stacks. That said, there's a fine line being drawn here. On the one hand you seem to request a professional level of self-discipline from those who publish libraries, while elsewhere suggesting that Rev be used by more newcomers and non-professionals. As long as there are people who haven't yet made a million mistakes, they will code in ways that don't prevent them. :) 2) Rich and easy to access documentation If you want to use a java library written by somebody else, simple, you get access to the API online and you know what method to call and how. You don't need to know *anything* about the inner workings of the library. Why is it? Because some some conventions have been created which let you comment your script in a very efficient way, where the API doc can be automatically generated from these comments. http://java.sun.com/j2se/javadoc/. There is *NOTHING* even close to this in revolution. Again, this is a matter of choice on the part of the developer. Some are simply more diligent documenters than others. While the number of lines needed to extract APIs from a Java code base is so great that Sun needs to provide a tool for it, getting a list of handlers from a script in Transcript can be done in just a few lines (see the MC IDE's Script Editor or Geoff Canyon's post at http://lists.runrev.com/pipermail/use-revolution/2006-March/078496.html). Modifying those routines to also include params would be trivial. But for such extraction to be useful the key is to provide meaningful parameter names. Remember that Java's a typed language so the prototypes will tell you more about a param than its name alone will. So again, this is a choice and some do it better than others. KR-style single-letter arguments won't tell you very much. :) (A few tips on naming conventions are shared at http://www.fourthworld.com/embassy/articles/scriptstyle.html). Taking this notion one step further, the Rev Interoperability Project (RIP) at http://groups.yahoo.com/group/revInterop/ offers guidelines for libraries to include API documentation, and in a way that makes it relatively simple for a single doc-reader stack to easily display the API for any RIP-savvy library. Conventions exist for both Java and Rev; they're only as useful as they are adopted, and Java is used by more professionals for whom the benefits of self-discipline pay bigger dividends. 3) Member's sense of investment in making their work freely available Yes, you can do fantastic stuff with revolution. But you have to start from zero and do
Re: Making the move...
Marielle, Most of us know, you have a running feud with those at RunRev. If you aren't happy with the tool, then just don't use it. It's that simple. Perhaps there aren't as many libraries available for Transcript, but who says using only reusable libraries is the only way to code quickly? I can still develop my apps significantly faster than enterprise customers who code in Java and .NET (even with all their free libraries!). As Richard has implied over and over, it's about ROI for the client. If I can program some apps faster than another developer, then I provide value for my client. It really is that simple. This is not to say Revolution is the perfect application framework for every type of project --though I've personally yet to find a project which it won't work for. Projects which require large teams of programmers (like Operating Systems for instance) are not a good match for Runtime Revolution. But for small groups who need fast results, Runtime Revolution works great...libraries or not. And for the record, Richmond was not 'banished' from this list for his views on Open Source. The first time, I believe he was banished for his choice of cursed language, and RR let him back on only to have him post to this list a hack to the RR website (which many of us would have only forwarded directly to RR). Your effort here to cast RR in a poor light regarding Richmond, Xavier and others is a disservice to those who don't know the whole story. -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Marielle- Friday, March 17, 2006, 4:44:16 AM, you wrote: 2) Rich and easy to access documentation If you want to use a java library written by somebody else, simple, you get access to the API online and you know what method to call and how. You don't need to know *anything* about the inner workings of the library. Why is it? Because some some conventions have been created which let you comment your script in a very efficient way, where the API doc can be automatically generated from these comments. http://java.sun.com/j2se/javadoc/. There is *NOTHING* even close to this in revolution. Here, if you want to find your way through ...sure there is. You have to roll your own, but it's not that much transcript code. My libraries generate their own documentation through a javadoc-like mechanism. Check out, for example, my ArchiveSearch plugin on revonline and open the libDispatcher library. Click on the API button. And the ECMI document was developed as a way to provide library developers with a standardized way of documenting the api, among other things. If library developers don't follow this then it's no different from java developers not supplying javadoc comments or providing api documentation online. They're just conventions that have become fairly universally adopted. Not knowing *anything* about the internal workings of a library can cause much more pain in java than in rev, especially in areas of throwing exceptions and threading. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 17 Mar 2006, at 18:26, Mark Wieder wrote: Marielle- Friday, March 17, 2006, 4:44:16 AM, you wrote: many Japanese management concepts such as Total Quality Control, Quality Control circles, small group activities, labor relations. Key elements of Kaizen are quality, effort, involvement of all employees, willingness to change, and communication. Having been involved with Total Quality initiatives, Quality Control Circles, etc, on this side of the pond I can say from experience that they are doomed to failure because of underlying cultural differences. Labor and social relationships are not structured in western societies to provide the level of trust and support required to allow them to be effective. Like Lynn, I've spent a long time in Japan, and my life still carries the trappings. I agree with what you say, Mark, but I think it isn't the whole picture. In the early 80s, a guy at a Japanese steel company explained to me how his time was being taken up with visiting Americans determined to learn the secrets of Japanese TQC. He felt they were wasting their time. Not because they were incapable of learning, but because there was nothing to learn. He said that Westerners will debate and evaluate various methods until they decide on the best approach. Japanese corporations, on the other hand, will take any method, good or bad, and make it work. Having subsequently worked with a number of large Japanese corporations, I think his comments were very shrewd. In other words, it's not that Japanese methods transferred to the west are doomed to failure, but rather that any method adopted by Japanese corporations is doomed to success. (But that was in the 80s, and plenty has changed since then.) Cheers Dave ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Making the move...
Hi all, I must have missed the fuse on this thread, sorry - I only caught it from Mark's response to Kaizen - sorry, Marielle, I accidentally deleted your list of concerns but have now a copy to review. Some of it Id like to discuss off list. Lets step away from the impending flames of non-product issues. Until Jacque finishes her time travel stack, there isnt much that can be done with history :-) 2006 will be a good year for Runtime as a company and Revolution as a product platform. There is a limit to the amount of detail I can go into in a public venue. There are some things we can discuss in more detail at RevCon West. I hope to all see you there. In the spirit of the season, please allow the baby bird to hatch out :-) Best regards, Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Making the move...
I agree with what you say, Mark, but I think it isn't the whole picture. In the early 80s, a guy at a Japanese steel company explained to me how his time was being taken up with visiting Americans determined to learn the secrets of Japanese TQC. He felt they were wasting their time. Not because they were incapable of learning, but because there was nothing to learn. He said that Westerners will debate and evaluate various methods until they decide on the best approach. Japanese corporations, on the other hand, will take any method, good or bad, and make it work. Having subsequently worked with a number of large Japanese corporations, I think his comments were very shrewd. In other words, it's not that Japanese methods transferred to the west are doomed to failure, but rather that any method adopted by Japanese corporations is doomed to success. (But that was in the 80s, and plenty has changed since then.) That's true - I don't think the mentality has changed since that time, though economic shifts did have its social impact. Failure really isn't an option - they make it work. But it is possible to use Japanese methods and have strong, cohesive, quality minded teams, even with a few Americans walking on the tatami mats with muddy shoes ;-) It is just extremely hard to achieve. Best regards, Lynn Fredricks Worldwide Business Operations Runtime Revolution, Ltd ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Lynn Fredricks wrote: Until Jacque finishes her time travel stack, there isnt much that can be done with history :-) 2006 will be a good year for Runtime as a company and Revolution as a product platform. Playing with the beta again, are you? ;) -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Interesting topic. I've probably logged over 30 trips to Japan since 1986. I once had the good fortune to meet with a Dr. Sasaki, the father of computer science in Japan for lunch. He was an original member of the ENIAC team here in the US. I mentioned to him that many years before, Japan had a reputation for cheap products, then they proved it wrong by creating high-quality products. I then mentioned the fact people said Japan couldn't create steel, to which they ended up virtually owning the steel industry. I furthered on with topics on consumer electronics, computers parts, computers, cars, etc..each time with Japan ultimately proving to the world their mastery of such industries. Finally, I said, the current knock on Japan was they couldn't develop software, and would they again prove the naysayer wrong? To my astonishment, he answered 'NO', the naysayers were correct. Japan would never be a great software development country. I asked him this 10 years ago, and didn't believe his answer. He gave 3 reasons for this: 1) The culture. Great software is typically created by a small group of only a few developers-- not the Japanese way of throwing manpower at a problem. Furthurmore, typcially good developers are not very social and can be obstinate (duh!), which again flys against the culture. And, the program all night when on a roll, then sleep all day type would never fly in a Japanese corporation. 2) It is very difficult for startup companies to begin in Japan. There are huge incorporation fees, plus it's almost impossible to go public, so it's difficult to find investors, Because the 'equity' of a software startup is not 'tangible', it's very difficult to get banks to become involved, and a good banking relationship is very important to startups. 3) Lastly, the best computer languages were based in English, and very different from the way Japanese read and write. I imagine much of this has changed in the past 10 years or so since we last talked, but I still believe many of his concerns have some validity. Of course, as recently as a couple of years ago, I toured a new CG Manga studio where people slept on the floor under the desks in makeshift tent-beds and generally had a more 'western' feel like many game studios do today. Of course, as they say, the proof is in the pudding. And, we've yet to see any big mainstream programs come out of Japan. But, there are some. I believe Shade 3D is a Japanese program (Lynn, you may know about this?). -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
I had the pleasure of serving tiramisu A gracious host, Richard G. is! Thanks for your full meal of a post as well as your deserts. Rich ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Marielle- Wednesday, March 15, 2006, 5:22:34 PM, you wrote: Simple: A method for outputting Java byte-codes equivalent to MetaCard scripts has been designed, but implementation has been delayed until the serious performance, compatibility, and functionality limitations in Java have been rectified. http://www.metacard.com/pi5.html Thanks indeed for the links. That one, however, seems to be circa-2003 vaporware. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Hi Mark, Marielle- Wednesday, March 15, 2006, 5:22:34 PM, you wrote: Simple: A method for outputting Java byte-codes equivalent to MetaCard scripts has been designed, but implementation has been delayed until the serious performance, compatibility, and functionality limitations in Java have been rectified. http://www.metacard.com/pi5.html Thanks indeed for the links. That one, however, seems to be circa-2003 vaporware. well, Dr. Rainey is not known for airy statements, actually ;-) -- -Mark Wieder [EMAIL PROTECTED] Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Dan Shafer wrote: With the caveat that I am hardly a Rails expert and certainly have not done a lot of work with Rev on the server side either, let me see if I can clarify my earlier point here. I know that what I'm going to say is probably so trivial to many reading this thread that it will seem like I'm just off base, but I'm trying to make the issue I see really starkly clear. I'm certainly no Ruby/Rails expert either, but I am among those attracted to the word impossible. :) Even though we've moved past that original point, there may be some interesting things to explore here. This one got a bit long (from me? Gosh, when did I ever write a long post? g), so I added section headers to try to make it an easier read: PARSING/ASSEMBLING THE CLIENT OUTPUT With PHP or Ruby on Rails, a Web *app* consists of a collection of 1 or more templates -- HTML files with embedded command and function calls -- that execute in a server-side scripting language interpreter running on the server. All Web pages with this embedded script code are run through the scripting language interpreter on the server, where the command is carried out and some content is generated to replace the command call before the page is sent to the HTTP server to return to the client. So for example (and I realize this is so simplistic that it may not be sufficiently illustrative), in a .rhtml (rubified HTML) file, you might find this construct: It is now %= Time.now % In Transcript: It is now [[the time]] You run that through the merge function: put merge(It is now [[the time]]) ...and you get: It is now 4:44 PM More interesting is that you don't need to use literal expressions with merge; you can pass it variables as well, with any number of bracketed statements, allowing you to make whole pages of snippets which have all the smarts of Transcript embedded throughout, processed in a single merge() call. And of course we all know about the other powerful text manipulation stuff in Transcript like chunk expressions and such, so we can move on to the bigger question of how we hook the engine into the web transaction process. HOOKING REV INTO THE SERVER TRANSACTION --- Most of the RoR documentation makes reference to FastCGI as the deployment mechanism for Ruby, and recommends using a specialized server app, WEBrick, for testing locally before deployment. It seems Rev has both of these covered. If I read Pierre's article at http://istream.homeunix.com/insead/index_en.html correctly, it seems we can use Rev as a daemon (at least on Linux), providing a stay-resident option just as one would do with other engines like Perl, Python, etc. I would imagine one could also set up Apache to use Rev for server-side includes, using settings similar to what's used for Ruby or PHP. Because the interest in using Ruby on web servers is relatively recent, I can't imagine there's anything in the server configuration that couldn't also be done with Rev (or Python or PHP other popular engines). In both cases you need to install the engine and set up the server so it knows what to do with it. There may be some reason that Rev can't be used with FastCGI per se, but given that it will run as a daemon on Linux offhand I don't know what that could be. If anyone here knows it would be interesting to find out, and even more interesting to find out if you've been able to use Rev with FastCGI successfully. PROS AND CONS OF REV AND RUBY - Beyond the configuration, there are two main differences between a Rev and a Ruby solution: OOP and Rails. The first is the age-old procedural vs. OOP argument. There are benefits both ways, and I dare not suggest we need to answer that big abstract question here. :) Where Ruby really shines is in Rails: there's a lot of code there, well-crafted code. You'd have to write that yourself to get to the same level of development productivity with Rev. But consider this about the origins of Ruby: Matz's primary design consideration is to make programmers happy by reducing the menial work they must do, following the principles of good user interface design. He stresses that systems design needs to emphasize human, rather than computer, needs. http://en.wikipedia.org/wiki/Ruby_programming_language Sound like another language we know? :) Personally, I think the only reasons we're reading about Ruby on Rails rather than Revolution on Rails are that both Ruby and Rails are open source, and there is no similar framework for Rev. While Rev isn't inherently OOP as Ruby is, it has its own favorable tradeoffs which make it quite attractive in its own right. FRAMEWORKS AND DEPLOYMENT OPTIONS - So what if someone took that much time to craft a web app framework in Transcript? I'm reminded of Andre's presentation at the first
Re: Making the move...
Forgive the intrusion from a 'lurker', but as I've learned so much from you all the last three months, it's time I gave something back. I'm developing using Ruby on Rails on both Windows XP Pro SP2 (Knoppix) Linux simultaneously. Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. A brief general comment. I use and modify the Ruby code to handle the 'unseen' parts, if you will, and Rev to generate what the user sees on the websites. I see Rev as complementary to ROR, and it seems to work well. A good mix. Cheers from Canada Peter Elliott Richard Gaskin wrote: Dan Shafer wrote: With the caveat that I am hardly a Rails expert and certainly have not done a lot of work with Rev on the server side either, let me see if I can clarify my earlier point here. I know that what I'm going to say is probably so trivial to many reading this thread that it will seem like I'm just off base, but I'm trying to make the issue I see really starkly clear. I'm certainly no Ruby/Rails expert either, but I am among those attracted to the word impossible. :) Even though we've moved past that original point, there may be some interesting things to explore here. This one got a bit long (from me? Gosh, when did I ever write a long post? g), so I added section headers to try to make it an easier read: PARSING/ASSEMBLING THE CLIENT OUTPUT With PHP or Ruby on Rails, a Web *app* consists of a collection of 1 or more templates -- HTML files with embedded command and function calls -- that execute in a server-side scripting language interpreter running on the server. All Web pages with this embedded script code are run through the scripting language interpreter on the server, where the command is carried out and some content is generated to replace the command call before the page is sent to the HTTP server to return to the client. So for example (and I realize this is so simplistic that it may not be sufficiently illustrative), in a .rhtml (rubified HTML) file, you might find this construct: It is now %= Time.now % In Transcript: It is now [[the time]] You run that through the merge function: put merge(It is now [[the time]]) ...and you get: It is now 4:44 PM More interesting is that you don't need to use literal expressions with merge; you can pass it variables as well, with any number of bracketed statements, allowing you to make whole pages of snippets which have all the smarts of Transcript embedded throughout, processed in a single merge() call. And of course we all know about the other powerful text manipulation stuff in Transcript like chunk expressions and such, so we can move on to the bigger question of how we hook the engine into the web transaction process. HOOKING REV INTO THE SERVER TRANSACTION --- Most of the RoR documentation makes reference to FastCGI as the deployment mechanism for Ruby, and recommends using a specialized server app, WEBrick, for testing locally before deployment. It seems Rev has both of these covered. If I read Pierre's article at http://istream.homeunix.com/insead/index_en.html correctly, it seems we can use Rev as a daemon (at least on Linux), providing a stay-resident option just as one would do with other engines like Perl, Python, etc. I would imagine one could also set up Apache to use Rev for server-side includes, using settings similar to what's used for Ruby or PHP. Because the interest in using Ruby on web servers is relatively recent, I can't imagine there's anything in the server configuration that couldn't also be done with Rev (or Python or PHP other popular engines). In both cases you need to install the engine and set up the server so it knows what to do with it. There may be some reason that Rev can't be used with FastCGI per se, but given that it will run as a daemon on Linux offhand I don't know what that could be. If anyone here knows it would be interesting to find out, and even more interesting to find out if you've been able to use Rev with FastCGI successfully. PROS AND CONS OF REV AND RUBY - Beyond the configuration, there are two main differences between a Rev and a Ruby solution: OOP and Rails. The first is the age-old procedural vs. OOP argument. There are benefits both ways, and I dare not suggest we need to answer that big abstract question here. :) Where Ruby really shines is in Rails: there's a lot of code there, well-crafted code. You'd have to write that yourself to get to the same level of development productivity with Rev. But consider this about the origins of Ruby: Matz's primary design consideration is to make programmers happy by reducing the menial work they must do, following the principles of good user interface design. He stresses that systems design needs to emphasize
Re: Making the move...
Peter Elliott wrote: Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. That would be enormously helpful. Thank you! If you come to RevCon West in June or Euro RevCon in November I'll buy the beverage of your choice at one of the get-togethers. It's the least I could do for such helpful information as the benchmarks. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Richard Thank you for the kind invitation! Given that I'm writing these server programs in aid of a certain well-known 12 Step program's online activities, and that it's doubtful I'll be at either event, more's the pity, please be advised you can Fed-Ex any kind of high-test caffiene-laden product (Saigon Dark beans, por ejemplo ...) to my office, anytime. All kidding aside, and now that I've de-lurked, of all the mailing lists and digest I receive, I find this one of the most fertile stimulating. I thank you all for that. I think I can safely commit to delivering benchmarks by Wednesday of next week and will be happy to do so. Peter Elliott Richard Gaskin wrote: Peter Elliott wrote: Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. That would be enormously helpful. Thank you! If you come to RevCon West in June or Euro RevCon in November I'll buy the beverage of your choice at one of the get-togethers. It's the least I could do for such helpful information as the benchmarks. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
How about a tutorial on how to set up Rev to use FastCGI. For those of us for whom a lot of these terms are totatlly new, it would be great to be able to take advantage of some of these tools. I know I'm already salivating at the possibilities of merge(), something I just learned about on this thread. W. On Mar 16, 2006, at 1:34 PM, Collabyrinth VPN wrote: Forgive the intrusion from a 'lurker', but as I've learned so much from you all the last three months, it's time I gave something back. I'm developing using Ruby on Rails on both Windows XP Pro SP2 (Knoppix) Linux simultaneously. Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. A brief general comment. I use and modify the Ruby code to handle the 'unseen' parts, if you will, and Rev to generate what the user sees on the websites. I see Rev as complementary to ROR, and it seems to work well. A good mix. Cheers from Canada Peter Elliott ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/16/06 10:13 AM, Richard Gaskin [EMAIL PROTECTED] wrote: I would enourage those interested in web apps grab Dr. Raney's mchttpd.mc and play with it a while. It's a thing of beauty to just open the stack, click the Start button, and call it with your browser. Hi, Richard, I am beginning to step toward the world of web apps and did the dnld of the mchttpd app, started it on a G5, but am not sure how to access it. Tried in Safari (on the same OSX 10.4.2 computer) ( IE on Win32 behind the same router) http://192.186.15.100 http://192.186.15.100/index.html = can't find the server Does the mchttpd computer have to have static IP? Although I am new at this, I know someone who might jump into Rev if he saw this working. Thanks. Jim Ault Las Vegas ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Wally As (your) luck would have it, we're working on exactly such a document for the poor unfortunates who will inherit the servers once I've wrought havoc on them. This is pro bono stuff for the fellowship AFAIC, for keeping me sober since 1979, so by all means, when it's done and relatively stable, I'll release it in the RunRev wild. Some of the stuff around FastCGI is a bit tricky, but I think the documentation will pull you through. If it doesn't, you know where to get me. So, about the coffee ... Peter Elliott Wally Rodriguez wrote: How about a tutorial on how to set up Rev to use FastCGI. For those of us for whom a lot of these terms are totatlly new, it would be great to be able to take advantage of some of these tools. I know I'm already salivating at the possibilities of merge(), something I just learned about on this thread. W. On Mar 16, 2006, at 1:34 PM, Collabyrinth VPN wrote: Forgive the intrusion from a 'lurker', but as I've learned so much from you all the last three months, it's time I gave something back. I'm developing using Ruby on Rails on both Windows XP Pro SP2 (Knoppix) Linux simultaneously. Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. A brief general comment. I use and modify the Ruby code to handle the 'unseen' parts, if you will, and Rev to generate what the user sees on the websites. I see Rev as complementary to ROR, and it seems to work well. A good mix. Cheers from Canada Peter Elliott ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Wow Peter, great! As one of the lurkers who has been toying with Revolution before taking a dive, this is indeed inspiring. Thanks, Michael On Mar 16, 2006, at 7:44 PM, Collabyrinth VPN wrote: Wally As (your) luck would have it, we're working on exactly such a document for the poor unfortunates who will inherit the servers once I've wrought havoc on them. This is pro bono stuff for the fellowship AFAIC, for keeping me sober since 1979, so by all means, when it's done and relatively stable, I'll release it in the RunRev wild. Some of the stuff around FastCGI is a bit tricky, but I think the documentation will pull you through. If it doesn't, you know where to get me. So, about the coffee ... Peter Elliott Wally Rodriguez wrote: How about a tutorial on how to set up Rev to use FastCGI. For those of us for whom a lot of these terms are totatlly new, it would be great to be able to take advantage of some of these tools. I know I'm already salivating at the possibilities of merge(), something I just learned about on this thread. W. On Mar 16, 2006, at 1:34 PM, Collabyrinth VPN wrote: Forgive the intrusion from a 'lurker', but as I've learned so much from you all the last three months, it's time I gave something back. I'm developing using Ruby on Rails on both Windows XP Pro SP2 (Knoppix) Linux simultaneously. Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. A brief general comment. I use and modify the Ruby code to handle the 'unseen' parts, if you will, and Rev to generate what the user sees on the websites. I see Rev as complementary to ROR, and it seems to work well. A good mix. Cheers from Canada Peter Elliott ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Peter, As a fellow 'coffee' drinker, welcome to the list. We keep what we have by giving it away. works real well in this environment too. Easy Does It, Tom On Mar 16, 2006, at 7:44 PM, Collabyrinth VPN wrote: This is pro bono stuff for the fellowship AFAIC, for keeping me sober since 1979, so by all means, when it's done and relatively stable, I'll release it in the RunRev wild. So, about the coffee ... Peter Elliott Thomas J McGrath III [EMAIL PROTECTED] Lazy River Software™ - http://www.lazyriversoftware.com Lazy River Metal Art™ - http://www.lazyriversoftware.com/metal.html Meeting Wear™ - http://www.cafepress.com/meetingwear Semantic Compaction Systems - http://www.minspeak.com SCIconics, LLC - http://www.sciconics.com/sciindex.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Jim Ault wrote: On 3/16/06 10:13 AM, Richard Gaskin wrote: I would enourage those interested in web apps grab Dr. Raney's mchttpd.mc and play with it a while. It's a thing of beauty to just open the stack, click the Start button, and call it with your browser. I am beginning to step toward the world of web apps and did the dnld of the mchttpd app, started it on a G5, but am not sure how to access it. Tried in Safari (on the same OSX 10.4.2 computer) ( IE on Win32 behind the same router) http://192.186.15.100 http://192.186.15.100/index.html = can't find the server Does the mchttpd computer have to have static IP? Although I am new at this, I know someone who might jump into Rev if he saw this working. The default port in mchttpd is 8080 -- on my Mac I use: http://localhost:8080/ -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Michael Well, I was looking for solution to fasttrack an entirely different project when I ran across Revolution. I've been running it on a Groundhog Day WinBox, but it's dive-time for me, most certainly. This list is also a very fertile group, I think, and that's helped immensely. Sometimes I think we programmers take far too much pride in the *complexity* of what we do, and shun truly productive environments because anyone can do it kind of thinking. (You're reading this from a guy who writes Pike/Ruby/PHP/C/SB code in a freeware editor just to be macho man because I'm surrounded by people 2/5ths my age. Job security.) This is a useful, powerful product, and the way it gets more exposure is if we turn out high-quality, attractive and powerful websites apps to prove it. With apologies to VB lovers anywhere, this ain't exactly Visual Basic. Regards, Peter [EMAIL PROTECTED] wrote: Wow Peter, great! As one of the lurkers who has been toying with Revolution before taking a dive, this is indeed inspiring. Thanks, Michael On Mar 16, 2006, at 7:44 PM, Collabyrinth VPN wrote: Wally As (your) luck would have it, we're working on exactly such a document for the poor unfortunates who will inherit the servers once I've wrought havoc on them. This is pro bono stuff for the fellowship AFAIC, for keeping me sober since 1979, so by all means, when it's done and relatively stable, I'll release it in the RunRev wild. Some of the stuff around FastCGI is a bit tricky, but I think the documentation will pull you through. If it doesn't, you know where to get me. So, about the coffee ... Peter Elliott Wally Rodriguez wrote: How about a tutorial on how to set up Rev to use FastCGI. For those of us for whom a lot of these terms are totatlly new, it would be great to be able to take advantage of some of these tools. I know I'm already salivating at the possibilities of merge(), something I just learned about on this thread. W. On Mar 16, 2006, at 1:34 PM, Collabyrinth VPN wrote: Forgive the intrusion from a 'lurker', but as I've learned so much from you all the last three months, it's time I gave something back. I'm developing using Ruby on Rails on both Windows XP Pro SP2 (Knoppix) Linux simultaneously. Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some benchmarks and publish the results next week, if it helps. A brief general comment. I use and modify the Ruby code to handle the 'unseen' parts, if you will, and Rev to generate what the user sees on the websites. I see Rev as complementary to ROR, and it seems to work well. A good mix. Cheers from Canada Peter Elliott ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
On 3/16/06 6:54 PM, Richard Gaskin [EMAIL PROTECTED] wrote: The default port in mchttpd is 8080 -- on my Mac I use: http://localhost:8080/ Woiks very good... cool. Is there a tutorial about how to put this in action on my G4 that has a static IP? I know that Apache would be the default receiver of 8080 traffic and I am definitely not a config-mechanic. Jim Ault Las Vegas Jim Ault wrote: On 3/16/06 10:13 AM, Richard Gaskin wrote: I would enourage those interested in web apps grab Dr. Raney's mchttpd.mc and play with it a while. It's a thing of beauty to just open the stack, click the Start button, and call it with your browser. I am beginning to step toward the world of web apps and did the dnld of the mchttpd app, started it on a G5, but am not sure how to access it. Tried in Safari (on the same OSX 10.4.2 computer) ( IE on Win32 behind the same router) http://192.186.15.100 http://192.186.15.100/index.html = can't find the server Does the mchttpd computer have to have static IP? Although I am new at this, I know someone who might jump into Rev if he saw this working. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Well, at least from the mc stack, you just run it and it seems to intercept the call on the designated port. You can manually change the port in the launch stack as well. PRetty cool stuff. On 3/16/06, Jim Ault [EMAIL PROTECTED] wrote: On 3/16/06 6:54 PM, Richard Gaskin [EMAIL PROTECTED] wrote: The default port in mchttpd is 8080 -- on my Mac I use: http://localhost:8080/ Woiks very good... cool. Is there a tutorial about how to put this in action on my G4 that has a static IP? I know that Apache would be the default receiver of 8080 traffic and I am definitely not a config-mechanic. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Richard. I *certainly* don't disagree with your response, but I'm earnestly seeking a description of how you'd go about building an app in Rev that is entirely deliverable via a Web browser, which is, I submit, the definition of a Web application. I think that was the original point/question. Creating thin-client Web appliances is amazingly easy with Rev. Creating CGIs that run on a server -- including back-end database access -- is also feasible, if somewhat limited in terms of performance (no FCGI support as far as I know). If this is possible, I'd sure like to know how to do it. On 3/14/06, Richard Gaskin [EMAIL PROTECTED] wrote: But if the goal is to deliver the benefits of productive, flexible systems, Transcript can prove quite capable in ways that may surprise. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Dan Shafer wrote: On 3/14/06, Richard Gaskin [EMAIL PROTECTED] wrote: But if the goal is to deliver the benefits of productive, flexible systems, Transcript can prove quite capable in ways that may surprise. Richard. I *certainly* don't disagree with your response, but I'm earnestly seeking a description of how you'd go about building an app in Rev that is entirely deliverable via a Web browser, which is, I submit, the definition of a Web application. I think that was the original point/question. Creating thin-client Web appliances is amazingly easy with Rev. Creating CGIs that run on a server -- including back-end database access -- is also feasible, if somewhat limited in terms of performance (no FCGI support as far as I know). If this is possible, I'd sure like to know how to do it. A web application has at least a web-based interface, and often also has a server-side component to it. There are three viable methods of making an interactive interface in a web browser: a) Java b) Flash c) DHTL (recently re-christened Ajax) Rev doesn't produce Java or Flash output, so if those are desired you would indeed have to go to another tool. But neither does Ruby. Nor is Ruby embedded in web browsers. Web browsers have only one universal language at this time: JavaScript, which is the heart of DHTML/Ajax. JavaScript is plain uncompiled ASCII text. It can be generated/assembled/sliced/diced by a Rev-based CGI just as assuredly as any other language, such as Ruby, can do so. Rev's merge function is enormously powerful, as are its chunk expressions and file handling. Smartly-designed snippets of JavaScript and HTML can be combined and recombined quickly and easily with Transcript. As for performance, most CGIs are loaded when called. The exception is FastCGI, employing a stay-resident option to minimize load times. Many ISPs preconfigure their Perl installations to use FastCGI, and FastCGI is the recommended interface when you install and set up Ruby. It may be possible to use FastCGI with Rev; I'll leave it to the server experts here to fill us in on that. When run as a CGI, the Rev engine loads _much_ faster than it does on the desktop, which is pretty darn fast as it is. As a CGI it doesn't need to initialize any of its GUI elements, so the load time on a decent server should be roughly on par with any other engine of equivalent size. It would be helpful is someone here has performance benchmarks on Rev as a CGI relative to Perl, Python, Ruby, and other server-side languages. If FastCGI cannot be used with the Rev engine, then indeed we can expect a performance disparity between the Rev engine and the Ruby engine. But impossible? I don't see how. One of the main bullet points for developing in RoR is the MVC implementation, but again that's not exactly new. Smalltalk had MVC, and there are implementations in most OOPs and many non-OOPs as well, including a few done in Rev to varying degrees. While the Rev ones have focused on native controls for triggers, one would have to write JavaScript triggers for web-based UIs, as they would with any browser-based implementation. Ruby is a fine language, and the on Rails framework is well thought out and very useful. But it's not magic; Ruby is just a language, its Rails just a framework, and I've seen nothing in it that couldn't also be done with Perl, Python, Rev, or any other CGI. There may be tradeoffs with runtime performance and development productivity, but I see nothing which would discount all web applications as impossible to do in Rev. And as you note, Rev does one thing Ruby can't: compliment the range of deliverables with a net-savvy desktop app (think maps.google vs Google Earth). While only useful in a subset of scenarios, it offers many benefits, esp. for intranets where employers are losing billions in lost productivity by providing open web access to their employees when all they really need is access to specific company- and vendor-specific resources. Rev-based net-savvy apps (or net apps, or net appliances, or thick clients, or whatever else one might call them) are like VPNs for the rest of us. And, as with Google Earth, there are UI benefits to such desktop implementations as well. All that said, there are two benefits to Ruby: most of the code you'd need is already written, and as open source it's all freely available. But while Ruby may have some advantages, that doesn't make using other languages to generate DHTML interfaces impossible. Taking this a step further, I'll close with an exercise for the reader: 1. Make a web app development tool in Rev for laying out and generating DHTML controls for web pages. 2. Now make the same tool in Ruby. ;) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com
Re: Making the move...
And as long as MCRev web applications servers have been my best incomes sources betwin 1997 and 200x, i just can add that Rev is, before J2SE or PHP and behind Ruby on Rails, a real firstclass web apps development platform. RoR is probably before Rev in about the apps deployment framework and Rev is probably lots before RoR about the development langage it self, at least in my humble mind because the transcript xtalk structure, because the rev engine, both more polished and able to let us design our web apps in less time than in building them in Ruby coding. A public accessible example app : http://www2.sahores-conseil.com/ citalis.xml Some design, downloadable material and guildelines : http:// istream.homeunix.com/insead/index_en.html :) Le 15 mars 06 à 05:46, Richard Gaskin a écrit : Dan Shafer wrote: Web applications in the sense Ruby on Rails defines them cannot be written in Revolution. Since that definition requires the Ruby language and that it be on rails, nothing can satisfy it except Ruby on Rails. :) But DHTML (or AJAX* as the kids now call it) is just ASCII, and Transcript is unusually adept at parsing, concatenating, and merging text. And behind the presentation layer a database is a database, and interfacing it is always only as graceful as the self-discipline of the developer, regardless of the language. Frameworks are not a new invention, and certainly not unique to RoR. If the goal is to meet someone else's very specific definition of a development paradigm, sure, Transcript may not be able to do exactly that. But if the goal is to deliver the benefits of productive, flexible systems, Transcript can prove quite capable in ways that may surprise. Extra bonus points: With Rev you have the option of moving beyond Web 2.0 as in http://maps.google.com/, and moving right up to Web 3.0 a la http://earth.google.com/. :) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com * I'm so old when I hear Ajax I think of http://en.wikipedia.org/ wiki/Operation_ajax. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Pierre Sahores www.sahores-conseil.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Richard Gaskin wrote: It would be helpful is someone here has performance benchmarks on Rev as a CGI relative to Perl, Python, Ruby, and other server-side languages. I don't have benchmarks, but Scott Raney once said that the load time of the engine when used as a CGI was insignificant. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Richard Gaskin wrote: All that said, there are two benefits to Ruby: most of the code you'd need is already written, and as open source it's all freely available. But while Ruby may have some advantages, that doesn't make using other languages to generate DHTML interfaces impossible. Taking this a step further, I'll close with an exercise for the reader: 1. Make a web app development tool in Rev for laying out and generating DHTML controls for web pages. 2. Now make the same tool in Ruby. An interesting side note to all of this is that RonR really doesn't do much with DHTML and javascript...they leave that up to the AJAX developers. RonR is primarly server oriented, and only provides basic html scaffolding as UI. There are a few groups trying to paste AJAX on top of Ruby, but it's not that easy (yet). Dan has first hand info on how easy/hard it is to deploy apps in RonR. I'm pretty sure one could right a framework similar to RonR in Rev using Rev CGI's but there's always the cgi performace issue. I think Pierre Sahores has figured out a way to use a single instance of RevCGI and the multiple port capabilites of PHP, though I don't remember the details. -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Le 15 mars 06 à 23:22, Chipp Walters a écrit : Richard Gaskin wrote: All that said, there are two benefits to Ruby: most of the code you'd need is already written, and as open source it's all freely available. But while Ruby may have some advantages, that doesn't make using other languages to generate DHTML interfaces impossible. Taking this a step further, I'll close with an exercise for the reader: 1. Make a web app development tool in Rev for laying out and generating DHTML controls for web pages. 2. Now make the same tool in Ruby. An interesting side note to all of this is that RonR really doesn't do much with DHTML and javascript...they leave that up to the AJAX developers. RonR is primarly server oriented, and only provides basic html scaffolding as UI. There are a few groups trying to paste AJAX on top of Ruby, but it's not that easy (yet). Dan has first hand info on how easy/hard it is to deploy apps in RonR. I'm pretty sure one could right a framework similar to RonR in Rev using Rev CGI's but there's always the cgi performace issue. I think Pierre Sahores has figured out a way to use a single instance of RevCGI and the multiple port capabilites of PHP, though I don't remember the details. http://istream.homeunix.com/insead/index_en.html ;) -Chipp ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Pierre Sahores www.sahores-conseil.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
Couldn't a person build a Rev app that runs continuously, interpreting information that comes in a various ports and returning the appropriate html data as needed? I mean, Rev can operate as a server. So, as long as you are willing to write in all html formulating, it should be doable. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Making the move...
http://istream.homeunix.com/insead/index_en.html ;) Le 15 mars 06 à 23:59, Jonathan Lynch a écrit : Couldn't a person build a Rev app that runs continuously, interpreting information that comes in a various ports and returning the appropriate html data as needed? I mean, Rev can operate as a server. So, as long as you are willing to write in all html formulating, it should be doable. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Pierre Sahores www.sahores-conseil.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
