Re: Content management systems
Metadot is being used a lot in Schlumberger and Sema intranet websites (Sema is a large European IT company) , among many other clients. It's also being used in a big French ceramics company called St. Gobain. The Open Source version is currently lagging behind our latest (closed-source) release by about three or four months. Our closed-source version is comercially available and comprises, basically, the open-source framework plus a number of useful add-ons. We also do custom additions to the framework (in fact tailoring the software is our main business). Installing Metadot can sometimes get complicated, but is usually a straightforward process. I think Metadot internals are easy to learn and customize, as we have been improving them constantly for the last year. If you know your way around mod_perl and object oriented Perl you should be able to tailor Metadot to your liking in little time. You can also choose to program your own add-ons using the APIs we provide for that. Hope that helps, Claudio Metadot bills itself as a portal product. I've even installed it briefly in the past, and it seemed relatively easy to setup customize. http://www.metadot.com/ The developer site is at http://www.metadot.net/. wow...this looks great, anybody actually use it? Maarten
Re: Mod_perl component based architecture
Michael wrote: Are any of the packages mentioned particularly suited to client content management packages where the client can manage some limeted page content text/graphics but not really mess with the overall page layout and site content. I'm about to start researching this but would like input from the experts. Maybe you can try our software. Metadot is a content management server side application written in mod_perl. All content management in it is done from client browsers. It can also be seen as an application framework providing User, Session and sophisticated Access Control management, all of these accessible from client browsers. (The site administrator, though, gets complete power to limit users access/modification rights to content, and can even set disk space quotas for them.) Metadot comes with an API that makes it easy to create specialized applications on top of it, as well as with a wealth of bundled apps for adding content such as uploaded files, text, images, content categories, discussion and polls. We are open source under the GPL, and we're backed by a big oil-services company. We've just released Version 4.0b. Among its new features are: -Support for windows (IIS and Activestate PerlEx) -A simple templating system to alter page layout/design -A facility to do recursive access permissions changing from the browser -A feature that turns discussions into mailing lists -Improved documentation -A developers support site at http://www.metadot.net I work for them, but a couple of years ago I would have wished to have the functionality we now provide for what my previous job required. :-) Claudio -- Claudio Garcia [EMAIL PROTECTED]
Re: Help with accessing system
Hi Rasoul, You may want to try Metadot for a framework that takes care of all that for you. Metadot is a GPL'd mod_perl application that provides user management, content management and access control all in one package. It provides an API that allows for the creation of pluggable apps that take advantage of said infrastructure, so you can focus on developing the particularities of your app and not so much on infrastructure. All infrastructure is accesible from a web browser. The permissions system, for instance provides a GUI that allows to attach permissions and ACLs (access control lists) to individual units of content for groups and for individual users. (ie. you can specify separate permissions for the different operations of your unit of content. eg. a 'Poll' unit of content can be set to grant voting rights to the members of group X, edit rights to 'John' and 'View Results' to the members of group Y. Metadot is available from http://www.metadot.com or from http://sourceforge.net/projects/metadot. Regards, Claudio Garcia Rasoul Hajikhani wrote: I need some advice on implementing an accessing system. I have already implemented a few systems that now require some sort of advance accessing mechanism. I say advance because some parts of the systems that I have written are accessible by all, and some other parts should be accessible by managers, and still some other parts accessible by even fewer people. Not only that, I am also required to determine the identity of the user (not very challenging here), but to display the methods (links, buttons, ...) that the user with his/her access level can use and click on. I am hoping for some suggestions. All comments welcomed. Thanks in advance -r
Re: [ANNOUNCE] RoboWeb 1.0b, web application test suitegenerator
I agree with you. RoboWeb is not informative enough for CPAN. I chose it for Sourceforge because it's catchy. :-) As it stands it is mostly a set of scripts, not modules. That's why I opted for putting it on Sourceforge rather than on CPAN. Do people here think it worthwile of being at CPAN under a name of its own? I would call it WWW::TestRecorder WWW::TestSuiteGenerator or HTTP::ProxyTestRecorder Jeremy Howard has suggested WWW:WebMacro (or HTTP::WebMacro) given the resemblance of recorded sequences to command macros in spreadsheet programs. (He has also been using the name WWW::Automate for his user agent API). I've been talking with Jeremy on making RoboWeb output WWW::Automate statements instead of the raw frozen HTTP::Request objects it currently does. I'm thinking that it would be best to make RoboWeb accept backend plug-ins so that it can better adapt to its users preferred client library. Please send any suggestions or feature requests you have. Claudio Gunther Birznieks wrote: If you guys end up finally collaborating, one very minor request I would have is that it goes into CPAN as something more standard like WWW:: namespace rather than a marketing name like RoboWeb. RoboWeb is actually a good product name (and in fact do a search on google for other tools with a RoboWeb label attached to them), but it really opens up room for misinterpretation in the future. And personally, I think these seem like indispensable tools that should be a standard CPAN addition. Calling it RoboWeb on CPAN will make it as confusing as figuring out which template solution to use -- but I suspect that web testing features can be fairly standardized (unlike templates). At 11:53 AM 7/23/2001 +0400, Ilya Martynov wrote: We should investigate how these 2 projects can work together when I'm done so that RoboWeb 'recorded' sessions can create WWW::Automate methods that utilise the structure of the page. The benefits of doing this are: 1- Resultant scripts are easier to interpret 2- Scripting apps that vary their form field names works. CG [..skip..] CG I look forward to seeing WWW::Automate and to working together on this. I've recently become maintainer of another testing module HTTP::WebTest. Stable version (released on CPAN) already has many interesting features (like response time tests, text matching tests, content size checks, support for both remote web server and local test modes). I'm working on its rewrite in modular style where tests modules are pluggable so it will be easily extendable. After finishing with it I thought about writhing proxy that records users actions and produces skeleton of test. Maybe joining our efforts have some sense. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
[ANNOUNCE] RoboWeb 1.0b, web application test suite generator
I have developed a semi-automatic test generator for web applications. I've called it RoboWeb and it's now available for download from sourceforge, hoping that it can be useful to others. The project page at sourceforge is http://sourceforge.net/projects/roboweb. Here's an excerpt from the README, and after it a comparison with Test::CGI, which is a tool at CPAN whose intent is similar. RoboWeb is a suite of Perl scripts that allow for recording live user browsing sequences and insert assertions during them to later reproduce and automatically verify correctness of output of a web application. Recording test sequences is easy: just fire the roboweb_proxy script and make your browser point to it. The proxy will generate a test sequence script as you browse and you can insert must_match commands in the recorded sequence by entering regular expressions directly in your browser's URL box. These commands get translated into assertions that will be run against the server response text when the sequences are reproduced, to verify that server responses are correct. RoboWeb will also automatically put your web application backend database in a constant 'test-scenario' state before recording test sequences and before executing test scripts. This allows for reliable testing of complex web applications. Also, the recorded test sequence scripts support cookies, which allows them to interact successfully with most web application. After you collect a number of test sequences you can execute them via the TEST script, which will produce standard perl Test::Harness output. COMPARISON WITH THE Test::CGI MODULE The intent of Test::CGI is almost the same. It's about crafting test sequences that will be run against a web application in an automated fashion. The main differences I see between both approaches are: 1. RoboWeb makes it much easier to generate a test suite, because test sequence scripts under it are almost completely machine generated, except assertions, which are easily inserted by entering regexps in the URL box as you browse through your app. Test::CGI instead requires that all HTTP requests be hand coded by the test writer. 2. RoboWeb runs against a live web server, versus Test::CGI, which runs web apps as standalone CGI processes. Test::CGI is less complete in this regard, because it doesn't allow to test apps in the environment they'll be running on (e.g. mod_perl apps that rely on persitent variables are not testable with Test::CGI). 3. The RoboWeb client (which uses LWP::UserAgent and an HTTP::Cookie jar) supports cookies, which allow it to test most web applications. Test::CGI does not support cookies. 4. Test::CGI cannot request plain documents, whereas Roboweb can. 5. Both RoboWeb and Test::CGI produce Test::Harness output. Regards, Claudio Garcia
