On 15 September 2010 15:31, Andre Garzia <[email protected]> wrote:
The trick is not to try to convert a > common Rev stack, if you try to convert all kinds of Rev controls and > stuff, > you end up basically reimplementing the engine, this is kinda hard. Agreed that would be hard short term, and probably doomed to fail long term. > TWO ENVIRONMENT FRAMES > ... Actions on the development environment do not work directly on > the stuff we're developing but instead talk to the backend server that will > follow the orders. > > WEB RUNNER CANVAS > ... I have a Rev WebServer external ready for this > project. Thats the second environment frame that I've mentioned above. It > understands only Javascript. > I don't see any need for this approach? perhaps you need to explain a bit more. What is wrong with getting the RevIDE to do all this client side? The only reason to do this server side that I can see is to build a business case around it. The RevIDe can do all this at lower cost - bandwidth etc, and there are no real maintenance issues with distributed rev tools nowadays. Don't get this. WEB SAFE TOOLS PALETTE & INSPECTOR > Replacing the tools palette with a Web tailored one with tools that we've > scripted ourselves. They can mimic standard Revolution tools such as > buttons > and fields but they are not in fact creating Revolution buttons and fields > but our own controls. We would also create our own inspector for setting > properties of our own self made controls. > I think this is almost right, except that the logic of replicating Rev controls is the wrong way round. Frankly the web controls are out of date, and less sophisticated no than those you find in JavaScript libraries. Also the audience and market is larger for people familiar with these existing JavaScript interfaces than the tiny Rev market. What is needed is to emulate the best and most robust JavaScript controls with Rev widgets - not the other way round. ... When we drop a button on the web runner > screen, a POST call is made to the web server that picks this and creates a > button javascript object, this is transparent to the developer. > Again I can see absolutely no reason for the web server to do this - it's more work, and what is the benefit? The dragging components onto the canvas, can be done in the IDE. I demoed this at the last conference with widgets that are under version control on the server. This way Rev becomes a HTML5/JS/CSS development tool. We don't have the > overhead of converting stacks to web because we're jumping that whole step > working directly with HTML5 and friends. This solves control placement and > interaction but does not solve script processing. > In MVC terms (as you say) - the controllers and models can be on the server. This server side code could be on On-Rev, but equally there is no reason when any good robust server code could be used in any language, we just need to wrap so that the RevTalk based IDE handles it for us in the background. As an aside, the code I've been working on is based around the idea that we can have a more robust Rev based workflow (which speeds up native Rev development), and has the side effect of producing server based "controller" code - that can be ftp'd / transferred to the server and work there in exactly the same way as it does locally. The aim is to enable the sharing of this portable abstracted code, and build it into intuitive workflows so that it is generated in a natural way as part of coding in Rev. SCRIPT PROCESSING > We would define a subset of RevTalk and create direct conversions from > RevTalk to JS. As time went on we would implement more and more of RevTalk > but some minimal subset should be enough for a start. Javascript is a > wonderful language and converting scripts to it is the most safe option. > Yes - I think we are on the same page here. I see a sub-category of shared code, which could be translated into JavaScript or other languages. People would do this in order to allow their projects to work with existing online frameworks, while allowing local prototyping in RevTalk. The workflow is natural, and allows for gradual evolution of code bases based on incremental incentives that benefit the end user. I think it could work, especially if it were part of an explicit open source / open content strategy by RunRev, in which they took and supportive but indirect role. > The elegance of this approach is that we can begin with a fastCGI engine > for > the script processing by directly executing RevTalk script on the FastCGI > process without translation.... > I still don't see any advantage to this - maybe I am missing something? And FastCGI is AFAIK not the way to go now anyway? We could build this and release under BSD license which would enable > business to use it in the commercial offerings and thus making it > attractive > and incentive sponsorship. .... This as it is defined needs no input > whatsoever from the mothership, it can all be done in Rev. > It does not need RunRev technically, but as they are really the only ones with a commercial incentive to make this work it works better with their support - especially as the nature of the Rev community at present is "lone wolf" - it is not trivial to get collaborative projects going. With regard to the BSD style licensing - yes that is a safe bet, but I would argue that there are better overall strategies to take which would include BSD style licensing. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
