Re: mod_perl2 Web Application Standard?
Hi, Hi, All this talk of MVC and a universal despatch mechanism has started me thinking about Java Web Applications and how they are bundled into a standard configuration (e.g., Java's Servlet standard 2.3) Would such a standard (albeit optional) be useful for mod_perl2? I think it would be useful for *Perl*. The desire for this is part of what drives the P5EE project (Perl 5 Enterprise Environment) over at http://www.officevision.com/pub/p5ee/ http://p5ee.perl.org/ No one gets too excited about this project yet because it is still experimental/preliminary/finding its way. However, progress is steady, and new contributors are always welcome. The P5EE project was a spin-off of the mod_perl list last October and ended up at [EMAIL PROTECTED] http://mathforum.org/epigone/modperl/spayskerdfeld http://mathforum.org/epigone/modperl/quoxveewo (and August 2001). http://mathforum.org/epigone/modperl/premangdoo/ http://mathforum.org/search/epi_results.html?textsearch=P2EEctrlfile=epigon e/modperl.ctrlbool_type=andwhole_words=yes For people on the mod_perl list who don't know about the project, you may want to familiarize yourself with it. Generally standards run contrary to the TMTOWTDI approach of Perl but there are some advantages in a 'minimal' mod_perl web application standard: http://www.officevision.com/pub/p5ee/ (see Philosophy) * ISP's could install mod_perl applications in a uniform/consistent way - (e.g., the standard should prevent name space collisions etc.) http://www.officevision.com/pub/p5ee/ (see Vision: Pervasive Deployment) * A subset of mod_perl methods could be selected as a basis for the standard allowing other 'container' servers besides Apache (e.g., like http://jetty.mortbay.org - except in Perl not Java) The abstraction in P5EE that you are speaking about is the Context. http://www.officevision.com/pub/p5ee/software/htdocs/api/Context-frame.html The design says that P5EE software can (conceptually) run in a variety of web containers or Contexts. P5EE::Context::CGI P5EE::Context::FCGI P5EE::Context::ModPerl P5EE::Context::ModPerlRegistry P5EE::Context::PPerl and even a number of non-web Contexts P5EE::Context::Cmd P5EE::Context::Daemon P5EE::Context::Gtk P5EE::Context::POE P5EE::Context::SOAP P5EE::Context::WxPerl Of course, I see Modperl as the dominant, high-performance container for web applications for the P5EE. * Software companies (not sure who) could provide replication/clustered/load balanced solutions based on this standard I envision open-source (Perl/CPAN) versions of P5EE::Context::ISAPI P5EE::Context::NSAPI to provide containers for other proprietary servers. Replicated Repositories and clustered/load-balanced Contexts are all part of the open-source vision, not restricted to some commercial provider. * Application configuration/management tools could be used to administer mod_perl application(s) on the same server(s) * We could share 'mod_perl' applications on CPAN more easily/quickly Ideally, I'd like to download a single mod_perl archive file (e.g., application.mod) place it in a 'standard' application directory and then point my browser to the new application. I share your desire. Is this something that could be considered with the next release of modperl2? I'm thinking of something that is really 'lite', not too prescriptive, but achieves the objectives above. Nigel
RE: Doing Authorization using mod_perl from a programmers perspective
FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
[OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 11:27 PM 10/23/2001 +0800, Gunther Birznieks wrote: At 09:45 PM 10/23/2001, Perrin Harkins wrote: Matt Sergeant wrote: OK, so what are we missing? ... Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. ... I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. Hi, This issue of a P2EE specification has come up before (and I participated in the discussion), but since it is off-topic for the mod_perl list, I would appreciate some referrals of where to go to discuss this. Last time this came up, I was referred to three different mailing lists (also, see http://lists.perl.org/). However, none of the lists were interested in the P2EE problem (including the PerlSDK list). If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. Stephen
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Nathan, At 11:06 AM 10/23/2001 -0600, Nathan Torkington wrote: Stephen Adkins writes: If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support viewcvs or similar for web browsing of the CVS repository? Stephen
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with ok with me messages or how about 'foo'? messages. Stephen
[OT] Re: IPC::Shareable
Hi, The shared memory segment was already created by another user, and it was created without permissions for you to write to it. Try the ipcs command to view existing shared memory segments. Try the ipcrm command to remove an old one. Stephen At 03:02 PM 10/16/2001 -0700, Rasoul Hajikhani wrote: Pardon the off topic thread, I am trying to make IPC::Shareable work with my script, however I get this error: IPC::Shareable::SharedMem: shmget: Permission denied at /usr/local/lib/perl5/site_perl/5.005/IPC/Shareable.pm line 456 [Tue Oct 16 14:44:15 2001] [error] Could not create shared memory segment: Permission denied Does any one know what's up?
RE: ANNOUNCE: Starting work on Apache::RedirectUnless
Hi, I have been following this thread with interest because I have been struggling with the same problem. I define it this way. * To achieve secure authentication which is widely supported, you need to use Basic authentication over SSL * All URLs which can be accessed with HTTPS can be accessed with HTTP * I secure certain directories with .htaccess and all of the links in my site which point to them are via HTTPS, so as long as people always follow the links, they will never transfer the password in clear text (essentially) over the network using HTTP. * However, if they type the URL directly into the browser and they *forget* to use https but rather use http, their password is exposed to network sniffers. I think that it was to solve this problem that J.J.Horner suggested the module. Any request to a secured area using HTTP would be automatically redirected to the same URL with HTTPS instead. Thus, the browser would never, ever be prompted to surrender the authentication credentials (password) in the clear over HTTP. Thus, I see great value to JJ's suggested module. Is there an easier way to safeguard against Apache prompting for a password over HTTP? Stephen At 01:41 PM 9/18/2001 -0500, Christian Gilmore wrote: A realm is defined by the following three things: 1) AuthName 2) ServerName (well, the server name in the URL actually) 3) Port (well, the port to which the browser is talking) If these three things are not always the same, the browser will prompt the user to re-authenticate. So, you cannot authenticate a user on your https port and magically expect that information to be passed by the browser to your http port. You'd have to do application-layer session handling with some kind of shared information across services. There are security implications to consider here... Regards, Christian -Original Message- From: 'J. J. Horner' [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 18, 2001 12:01 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ANNOUNCE: Starting work on Apache::RedirectUnless The problem with that solution is that we have 2 virtual hosts, one http, one https, on one machine. https is the only available transport outside of our network, while the http server is available internally. This is a production webserver, with existing information, applications, etc. We don't want to redesign our existing setup just to move content to a secure virtualhost when someone wants to authenticate. This approach allows us to keep things from the developer side very transparent. Developers can continue to maintain and create as usual, with the added step of a login being transferred by https method. If I were designing a server from scratch, I would plan better, but since we are trying to implement encrypted basic authentication after the server, sites, applications are in place, we have to work around them. With the AuthName set to one value across the server, we may be able to prevent too many logins. We need to keep the same content on both virtualhosts as much as possible. Ideas? Comments? Thanks, JJ * Christian Gilmore ([EMAIL PROTECTED]) [010918 11:36]: Putting it into the auth phase would be appropriate, but I have to wonder why this module is needed other than to refrain from keeping your configuration file clean. Your unsecure virtual host should have no auth statements in it if you want all auth to be on your secure virtual host... You'll need to have your entire session where you want the user to authenticate on the same virtual host, else the user will be prompted multiple times or you will have a security gap if you're leaving it all up to the service layer. Regards, Christian -Original Message- From: J. J. Horner [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 18, 2001 8:51 AM To: [EMAIL PROTECTED] Subject: ANNOUNCE: Starting work on Apache::RedirectUnless I have need of a module that will redirect to https anytime basic authentication is required. I figure the best way to do this is to step in at the authentication phase, and should authentication be required and the method be http, redirect to https for any and all basic authentication traffic. Perhaps after this, redirect to http, if desired. Any comments or suggestions? Thanks, JJ -- J. J. Horner H*,6d6174686c696e40326a6e6574776f726b732e636f6d *** H*,6a6a686f726e65724062656c6c736f7574682e6e6574 Freedom is an all-or-nothing proposition: either we are completely free, or we are subjects of a tyrannical system. If we lose one freedom in a thousand, we become completely subjugated. -- J. J. Horner H*,6d6174686c696e40326a6e6574776f726b732e636f6d *** H*,6a6a686f726e65724062656c6c736f7574682e6e6574
Re: [OT] WebMacro (was: RoboWeb 1.0b, web application test suite generator)
Hi, Please be aware that WebMacro is a moderately popular Java templating tool hosted at http://www.webmacro.org Naming it WWW::WebMacro might be a bit confusing. It's your choice. I just wanted to make you aware of the other WebMacro. Stephen At 08:48 AM 7/25/2001 +1000, Jeremy Howard wrote: 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. The current plan is for the 'scripting language' which provides a simple interface for scripting interactions will be called 'WWW::Automate'. The project that combines RoboWeb and WWW::Automate into a flexible recorder for web interactions might be 'WebMacro' which would appear in CPAN as 'WWW::WebMacro'. These are all preliminary suggestions and open to discussion. HTTP::WebTest already is in an appropriate place in the hierarchy, and is descriptively named. HTTP::WebTest will probably be able to use WWW::Automate scripts (either as a plugin in just through its generic Perl API) but this doesn't require any new project or name. If anyone is interested in contributing, note that RoboWeb is already on SourceForge, and WWW::Automate will be up in the next week or two. Contact me privately if you'd like more information on getting involved.
Re: Real Widgets and Template Languages
Gang, First, a reminder to sign up on perl-widget-developer if you want to keep up with this thread. Already there are posts going there that are *not* going to modperl. http://sourceforge.net/projects/perl-widget We have achieved Milestones 1 and 2. * Milestone 1 - a proof of concept prototype of code * Milestone 2 - a SourceForge project set up for it ... Then given the assumption that those objects are simple, many more people can implement them. If I have to be concerned about a lot of stuff everytime I make a widget like multilingual support hooks and event hooks then I will never write a widget because I don't have time. This is why I want widgets to be tiny and atomic. Let's make it simple. If you want multilingual can there be some way of making the multilingual features a wrapper around existing atomic widgets? Same for events and other such expert features. ... It is absolutely my intent to satisfy the minimalist's needs. Gunther intends to use these widgets in a simple and elegant way which represents how *many* people will first use the Perl Widget Library. I promise that simple widgets will be simple to write. Frankly, complex widgets will be pretty simple to write. I want a module that fits into people's *existing* software. After that, they may find it valuable to expand and use the other features. I envision the following four user-driven Milestones. (Real users, real value!) If we satisfy the first-round needs of Gunther, Jay, and Stephen, we will have a set of software which meets many of your needs out there. Please do *not* discuss this post on the modperl list, only on perl-widget-developer. I also don't want to put a lot of emphasis on what feature is in what release. Essentially, this is my attack plan. Any of you are free to accelerate the development of one or another feature. o Milestone 3: get it ready for Gunther Birzniek's needs x get HTML generation of Pods working to own site x get rid of -w warnings in cgi-bin/cgiexample o add named-parameters to constructors: Controller, State, Config o add named-parameter, state_args = $cgi o resolve $widget-value() and $widget-values() * When Gunther is happily using the PWL in his application, we will consider this milestone achieved. * Gunther, I am close to a release that I think will be usable to you. I may then need you to write a Widget::Config::Extropia or whatever and give me feedback on what sucked about the API. After that I need you to come up with a detailed checklist of changes that need to be made to achieve the milestone. (Of course we will discuss it all on the perl-widget-developer mailing list.) o Milestone 4: internationalization for Jay Lawrence's needs o incorporate concepts of internationalization (string lookup) o add Widget::HTML::TextLabel (?) widget with internationalization abilities o add Widget::HTML::Money (?) widget with internationalization abilities * When Jay is happily using the PWL in his application, we will consider this milestone achieved. * Jay, same for you as for Gunther. I just put his milestone before yours because I want to make the simple things simple. But of course we will be working on it all at the same time. o Milestone 5: enhance the vision for Stephen Adkins' needs o add Widget::HTML::Template widget o add Widget::HTML::DualOrderedMultiSelect widget o incorporate a parent concept into widgets, and event bubbling o incorporate concept of browser sensitivity o add support for Javascript in the head o add cgi-bin/wexec (CGI script for running full-widget UI) * When Stephen is happily using the PWL in his application, we will consider this milestone achieved. o Milestone 6: Release as Widget-1.00 and announce to modperl and Perl community o get Pod documentation of classes up to speed o create a better statement of what this is o create a list of have you ever wished that... ? questions to interest people o add mod_perl support
Re: Real Widgets and Template Languages
At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote: At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: Hi, Development of a straw-man set of Perl Widget Library core classes is going well. A Sourceforge project (perl-widget) is in the process of being set up too. (I will announce when it is set up.) ... The state information can be accessed from *any* source by implementing an appropriate Widget::DataSource::State class (and using some additional, not-yet-implemented arguments to Widget-controller()). I think it would be better as a Widget::State::DataSource rather than the other way around. From the way you describe it, this is really an interface to getting state information that should be retrieved from a DataSource specific state driver. I have come to the same conclusion. I am changing the design to have three core base classes (other than the widgets): Widget::Controller Widget::Config Widget::State A CGI program might run with the following derived classes: (These are the initial defaults I am working on.) Widget::Controller::CGI Widget::Config::XML Widget::State::CGI All of these drivers may be overridden, as long as the driver you replace it with conforms to the interface definition described by the core base classes. (Kind of like a Java interface. You would be encouraged to derive from the core base classes, but that is not necessary.) ... I don't understand the Widget::Controller. Can you say more about this? The Widget::Controller (or perhaps, Widget::CGI::Controller) is the container class that you spoke about in your original post. I call it a Controller rather than a Container because I envision it being able to dispatch events generated by the widgets. Ah. I just want something to contain the widgets essentially. So perhaps from my perspective events aren't necessary and I would potentially just place the widgets into an array representing my HTML screen. I have found that event handling comes in surprisingly handy even for simple tasks. Essentially, it allows widgets to define callbacks. For instance, the DateDropDowns widget defines an event change (modelled after the Javascript onChange event) that, when triggered, concatenates the , MM, and DD back into -MM-DD. The following is working code. Notice that the $wc-dispatch_events($query); statement takes care of whatever widget housecleaning there may be (in this case, recomposing the date as a single variable from the three drop-downs). :: cgisample :: #!/usr/local/bin/perl -w ## # cgisample ## # This is an example of a CGI script that uses the capabilities # of the Perl Widget Library minimally. # It looks like any other perl script which uses the CGI.pm # library. # See 'wexec' for an example of a CGI script that uses # the full capabilities of the Perl Widget Library. ## use lib /usr/ov/acoc/dev/src/Widget; use CGI; $query = new CGI; use Widget; $wc = Widget-controller(); $wc-dispatch_events($query); print EOF; Content-type: text/html head titlecgisample/title /head body bgcolor=#ff h1cgisample/h1 hr form method='POST' EOF $anniv_dt = $wc-widget(anniv_dt); $button = $wc-widget(check_it); print Anniversary Date: , $anniv_dt-html(), br\n; print $button-html(), br\n; print Your anniversary date appears to be: , $anniv_dt-value(anniv_dt), br\n; print EOF; /form /body /html Also will we require XML to configure? Or is this also an optional feature that you more or less want for yourself but others can choose to not use? Configuration data is read in via the Widget::Config class, and this class can be replaced with a class which reads config data from any other source, as long as it conforms to the same calling interface. I was under the impression that XML was your desired means of writing a config file. Do you have a preference to use something different? I like XML for Config files, we use that in our Java stuff all the time. But Perl is one of the nicest and flexible config file languages out there. IE My config file is Perl. Anyway, I think it is weird to think of configuring just widgets. Usually you configure an application and widgets are a part of that. But everyone here will have a different way of preferring to write their application config whether it's XML or Perl and what features of these that are used (eg just a set of scalars or references to hashes or ... ?) or in the case of XML using attributes versus subtags... I had the hunch that everyone's configuration needs would be different. Hence the Widget::Config (interface) and Widget::Config::XML (driver) design. (Thanks for the input.) I am not quite sure that the configuration is so extensive for each individual widget that it can't be done by having a named parameter constructor similar
Re: Real Widgets and Template Languages
At 05:27 PM 5/29/2001 +0200, Issac Goldstand wrote: My $0.02 on XML config files. Although they may be attractive to some, personally, I don't like them. I see XML is merely the expression of the configurable parameters of the object. IE it is just a means to the end. Personally, I would like to define my widget properties through a GUI and then will probably use Storable to dehydrate and rehydrate my widget objects. I would never want to code up XML data and I don't think I'm alone. :) Definately when it comes to interchanging your widget data with another system something like XML really starts to make sense. I don't think it makes sense necessarily for your internal day-to-day operations. What I would advocate is that there are a variety of sources for widget configuration data from something as simple and elegant as Perl code to XML of some layout to Storable data stored in a blob field of a DBI source. Actually, I personally think that you're both correct here - I think the proper way to stash the widgets would be through Storable. If you wish to do it through XML, then that should call for an extension to Storable which can store/retrieve data from XML. Issac I completely understand what all three of you are saying, and I think the needs of the Gunther and Jay are being accommodated in the new design. However, a note on XML and Storable ... The XML::Simple class allows you a cache option (which I am using) where it caches the perl data structure in a Storable. The XML::Simple class reads the XML file into a perl data structure, then stores it as a Storable. On subsequent reads, it checks the timestamps of the .xml file and the .stor file and only rereads the XML file if it is newer than the .stor file. Otherwise, it just reads the .stor file. This appears to be about 3x faster. It would be kind of interesting if the Storable class were extended to store as XML ... ;-) Stephen
Re: Real Widgets and Template Languages
At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote: At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote: ... $widget = $wc-widget(first_name); print First Name: , $widget-html(), \n; A widget type has already been defined. So I don't see that the method to output it's display should be called html() which is, well, HTML specific. I prefer print First Name: , $widget-display(), \n; Since widgets are components that know how to display themselves whether its WML or HTML or whatever. This is a philosophical design decision that I have been struggling with. The widget does indeed know that it should generate HTML, so it could have a method, $widget-display(), $widget-draw(), etc. However, this implies that the widget has the freedom to decide how it should render itself and that the caller does not need to know. This is not correct. The caller in this case has already cooked up a bunch of HTML and is counting on the widget to produce HTML which can be inserted. The widget does *not* have the freedom to render any other way. This is why I have (sort of stubbornly) stuck with the $widget-html() method despite the unanimous suggestions for a $widget-display() method. I do believe there is a place for a display() method, but it is at the controller level. The is the level at which the caller may not know what technologies are being used by the widgets. This whole discussion brings out two other important design decisions. 1. What are the UI technologies we really wish to support? (i.e. is this *really* a Widget or an HTML::Widget library?) 2. Which classes represent Logical Widgets and which Physical Widgets? 1. TECHNOLOGIES I propose that the following technologies will have supporting Controller/State/Widget combinations to make this not just another web widget library. * CGI/HTML - a web application * mod_perl/HTML - similar, a web application using mod_perl * WAP/WML - driven from a WAP device * X11 (Gtk-Perl)- an X windows application * Curses (terminal) - a screen-oriented terminal application * Term - a line-oriented (scrolling) terminal application * Cmd - similar to Term, but the state must be saved between each cmd (I know I'm stretching the paradigm a little bit here, probably beyond what is reasonable. If you don't think one or more of these is a good idea, please keep it to yourself. I have a vision for it, and even if it's not very useful, it will shape the abstractness of the design elements. On the other hand, I would welcome suggestions for additional UI technologies that I might consider supporting.) One of the primary design rules is to *not* fall into the least common denominator trap. Many cross-platform application frameworks have done this and failed. Rather, the design goal is to *enable* the widget to fully utilize the capabilities of the technical environment it is in. This brings me to the next topic. 2. LOGICAL vs. PHYSICAL USER INTERFACE ELEMENTS I have spoken about the separation of the logical and physical user interface. This facilitates applications being written to the logical interface. The physical UI is then determined at a combination of configuration-time (config file) and run-time (user preferences, browser capabilities, etc.). As the library has developed, it has become clear that the logical UI is really only a figment of the coder's imagination, represented by code like $widget = $wc-widget(file_name); However, the Widget::Controller ($wc) decides (based on config and runtime values) which *physical* UI widget is returned. This could be a drop-down list box (select), a text box, a set of radio buttons, or some sort of complex/compound file chooser widget. So when you code a widget, it is a physical widget. The selection between physical widgets in order to fulfill the requirements of the logical widget are all decided by the Widget::Controller. Similarly if the Controller is a CGI/mod_perl Controller, it will only choose HTML widgets, whereas if the Controller is a WAP Controller, it would only choose WML widgets, etc. Note: This allows you to write physical widgets which are tied intimately with a particular browser version. The Controller and Config mechanism would *allow* you (not force you) to write an application that falls back gracefully and uses other physical widgets for different browsers. A Menu widget using all sorts of whiz-bang DHTML on IE 5.0 could be rendered sanely using a different visual paradigm on an NS 2.0 browser (or Lynx, or Curses!) using a different physical widget. This brings us back to the debate over the display() method vs. the html() method. Every widget class only runs in a certain environment. An HTML widget is being told to emit HTML, hence the method name html(). In addition, the display() method really does not display anything. It simply returns HTML. It is only displayed when the HTML is printed to STDOUT
Re: Real Widgets and Template Languages
At 10:04 AM 5/29/2001 -0700, [EMAIL PROTECTED] wrote: On Tue, 29 May 2001, Stephen Adkins wrote: Right. I have many more requirements I eventually want to support (such as internationalization). The trick is making the design such that it works in the simple case for simple things, while supporting advanced features for those who wish to use them. I think it is coming together pretty well. I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off the top. If my widgets aren't multilingual then I'll have to go elsewhere. 75% of my apps are bi and trilingual. I think we should bite the bullet and start talkin Unicode and ISO-639 language codes right at the beginning. OK. The priority of internationalization has been increased. Here is the first snapshot of code. http://www.officevision.com/pub/Widget/ Soon I will have the Sourceforge site up and we can stop clogging up this mailing list. Stephen
Re: Real Widgets and Template Languages
At 03:42 AM 5/30/2001 +0200, Issac Goldstand wrote: Wait a second, here... I was under the assumption that the Widget library was not going to be limited to HTML output only. According to your page, it seems that the only customization that you plan on doing is to modify the HTML to work properly with specific browsers (eg, MSIE vs Mozilla/Netscape). ... Issac Don't get worked up. The documentation on the page is about a week old. http://www.officevision.com/pub/Widget/ The link to the code is the only new addition. All of the comments you have read on this mailing list are accurate. I recommend you download the code, take a look, then comment. Stephen
Re: Real Widgets and Template Languages
Hi,
Development of a straw-man set of Perl Widget Library core classes is
going well. A Sourceforge project (perl-widget) is in the process of being
set up too. (I will announce when it is set up.)
The first 0.01 release will be for public comment on
the structure and concepts of the core classes.
With regard to all of the debate on closures/classes/etc., let me say that
I intend for the PWL to be useful in a variety of environments with
different people using more or less of the features.
I am favoring flexibility over performance at the moment, so full classes
are being used to access the different features of the different systems
with which it will need to interface.
At the low end, the PWL will support the simple use that Gunther requires:
simple generation of HTML of a named widget based on configuration
information.
At the high end, Jay Lawrence and I envision much more sophisticated
features ...
but let's not let the consideration of those get in the way of
accomplishing our
first task as described above.
A Template Toolkit user should be able to say
[%PERL%]
use Widget;
$stash-{wc} = Widget-controller();
[%END%]
Birth Date: [% wc.widget(birth_date) %]
or eventually something simpler like
[% USE wc = Widget %]
Birth Date: [% wc.birth_date %]
and the appropriately configured HTML will be inserted.
For non-users of Template Toolkit, they can do the comparable perl ...
use Widget;
$wc = Widget-controller();
$widget = $wc-widget(birth_dt);
print Birth Date: , $widget-html(), \n;
The rendering of this widget as HTML requires at least the following
* config information (Widget::Config)
* state information (to get the current value) (Widget::CGI::State in a
CGI environment)
The state information can be accessed from *any* source by implementing an
appropriate
Widget::DataSource::State class (and using some additional,
not-yet-implemented arguments
to Widget-controller()).
see below for more comments ...
At 11:10 PM 5/28/2001 +0800, Gunther Birznieks wrote:
At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote:
...
I have done the Widget.pm convenience functions and factory code.
I am working on the Widget::Config class to read XML config data using
XML::Simple.
Then on to Widget::Base a parent class for all implemented widgets.
Then on to Widget::Controller which will be handed a CGI object
(or Apache::Request or whatever using one of the much-commented on schemes)
and dispatches events detected from submit buttons, etc.
Then I do my first actual widget, Widget::HTML::Date.
I'll camp on this while I get lots of feedback.
I don't understand the Widget::Controller. Can you say more about this?
The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
container class
that you spoke about in your original post. I call it a Controller rather
than
a Container because I envision it being able to dispatch events generated
by the
widgets.
Also will we require XML to configure? Or is this also an optional feature
that you more or less want for yourself but others can choose to not use?
Configuration data is read in via the Widget::Config class, and this class can
be replaced with a class which reads config data from any other source, as
long as
it conforms to the same calling interface.
I was under the impression that XML was your desired means of writing a
config file.
Do you have a preference to use something different?
Thanks,
Gunther
Stephen
Re: Real Widgets and Template Languages
I don't understand the Widget::Controller. Can you say more about this? Also will we require XML to configure? Or is this also an optional feature that you more or less want for yourself but others can choose to not use? Hi, Below is running code for the Perl Widget Library. So far, there are only two widgets. * a generic Widget::HTML::Element * a drop-down menu Widget::HTML::Select Are there early comments on the interface from Perl? Is this shaping up into what was desired? Stephen shark:/usr/ov/acoc/dev/src/Widget/examples more Widget.xml Widget.2 :: Widget.xml :: config widget name=first_name tag='input' type='text' size='14' maxlength='99'/ widget name=last_name widget-class='Widget::HTML::Element' tag='input' type='text' size='14' maxlength='99'/ widget name=birth_dt widget-type='date'/ widget name=sexwidget-type='sex'/ widget-type name=date tag='input' type='text' size='14' maxlength='99'/ widget-type name=sex widget-class='Widget::HTML::Select' domain='sex'/ domain name=sex item name=M label=Male/ item name=F label=Female/ /domain /config :: Widget.2 :: #!/usr/local/bin/perl use lib ..; use Widget; my ($wc, $widget, @widgets); $wc = Widget-controller(); $widget = $wc-widget(first_name); print First Name: , $widget-html(), \n; $widget = $wc-widget(last_name); print Last Name: , $widget-html(), \n; $widget = $wc-widget(birth_dt); print Birth Date: , $widget-html(), \n; $widget = $wc-widget(sex); print Sex: , $widget-html(), \n; shark:/usr/ov/acoc/dev/src/Widget/examples Widget.2 First Name: input name='first_name' maxlength='99' size='14' type='text'/ Last Name: input name='last_name' maxlength='99' size='14' type='text'/ Birth Date: input name='birth_dt' maxlength='99' size='14' type='text'/ Sex: select name='sex' option value='M'Male/option option value='F'Female/option /select
RE: Concepts of Unique Tracking
How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
Re: Real Widgets and Template Languages
Jay, I think that pretty much describes what I have in mind ... plus a few other features. Hopefully within a week or two (based on demands of other *paying* jobs), I will have a working distribution with most of the bare-bones plumbing in place and a little configurable date widget implemented. This will allow me to solicit feedback on the plumbing and concepts before I go hog wild on implementing a host of widgets. (In fact, I predict the package will be downright boring for a month or more, to those who don't want to shape its development, while I get the concept and the internals right.) I have done the Widget.pm convenience functions and factory code. I am working on the Widget::Config class to read XML config data using XML::Simple. Then on to Widget::Base a parent class for all implemented widgets. Then on to Widget::Controller which will be handed a CGI object (or Apache::Request or whatever using one of the much-commented on schemes) and dispatches events detected from submit buttons, etc. Then I do my first actual widget, Widget::HTML::Date. I'll camp on this while I get lots of feedback. Stephen P.S. I have submitted an application for a Sourceforge project called the Perl Widget Library. The short name is perl-widget. I am waiting for approval from Sourceforge. This won't hold me up though. I plan on posting distributions on my web site. At 12:28 PM 5/24/2001 -0400, Jay Lawrence wrote: Hey all, Let me describe what I have been imagining as the ideal widget for what I am writing: 1 - it can look to its environment to determine how to render itsself - am I on an HTML page or something else? 2 - it has properties that can be set and remain static no matter who's using it - size, shape, colour, max, min 3 - it has properties that are customized by the individual user of the widget - current value, theme choice, 4 - it can tell developers and environments what it can do - switch_on, switch_off, increment, decrement, etc. 5 - it is capable of persisting from invocation to invocation - user 1 sets current_value to x - which always comes back for user 1 6 - it can look to its environment for interhitable properties - global theme choice, global font, etc. 7 - templating systems know how to call widgets - because they always use the same method to display themselves 8 - widget can interact with each other - increasing value on slider widget changes current record # value for database record widget 9 - access restrctions - users can override some values but not others - not everyone can even use this widget, etc. 10 - multilingual - some things are language neutral others are not - size would probably be neutral whereas label would be language sensitive 11 - above all it is easy to use - ie/ don't make me set a zillion properties just to make it work! I am going to throw out a buzzword, gasp, which may serve as a model for what we are talking about: JavaBeans. I do feel there is a lot of additional complexity there but it is along the right direction IMHO. If you translate my wishlist into technologies I think I am talking about: A - a good persistant object management environment B - user sessions C - integration of widgets (objects) to user sessions D - Object API (properties and methods) which are consistant and predictable E - self documenting objects This is what I have been looking for/writing myself! I am really eager to chip in on this project and get it going ASAP - but do acknowledge the need for hearty discussion about what people really want not just my own views. :)) Jay
Re: Real Widgets and Template Languages
Hi, I will step up to write this code. (if it is what I think it is) I have responded to the message by beginning a requirements document. http://www.officevision.com/pub/HTML-Widget/ Please read it and send me any comments. The following are the questions I need advice on in order to proceed. * What CPAN package namespace should I use? I studied the existing packages, and what we are trying to do looks like it fits under the existing top level package HTML. I propose to take the space HTML::Widget (see package layout in design doc). Gunther suggested the top-level Widget name space. I was under the impression that we should stay away from creating new top-level entries at CPAN unless there was really *nothing* similar. Confusingly, there is already an HTML::Widgets. Thoughts? * What CPAN packages should I begin with and build upon? CGI and Apache::Request were mentioned. I figure I will use these. HTML::StickyWidgets was also mentioned. Do you mean HTML::StickyForms? Are there others I should build dependencies on? * Should I begin immediately with a new Sourceforge project? another way? The codebase I will begin with is in CVS on my local server. Perhaps I should just continue that way and post versions to CPAN for distribution. However, we may have email traffic for the project that exceeds the general interests of the modperl list. Thoughts? I would need to get enough responses from people who would join that Sourceforge mailing list before it would be worth it to go do that. Stephen There has been some discussion on the list lately about generating widgets ala CGI.pm, HTML::StickyWidgets etc... The thing is that these products or plug-ins are very HTML oriented. The widget is defined as an HTML widget like a textfield or checkbox or dropdown or what-have-you. What I am really looking for is a library that abstracts and allows widgets to be developed that are tied to an application not to a set of HTML necessarily. I guess I will start by providing an example of what I want based on what we currently do in our Java framework when he use Templating there. I'd like it if someone has developed the same thing in Perl that we could reuse, otherwise, we may need to write this. ... snip ...
