On 2/9/2012 2:23 PM, Jonathan Swartz wrote: > Christian: How do you mean "fully work"? You mean with the ability to edit > things? > > I'm not sure how much of a site Mason needs going forward, maybe something > like http://moose.iinteractive.com/ with a few pages, and otherwise relying > on external web services like metacpan.org/github/stackoverflow/etc. > > I would like to archive the old wiki somewhere for posterity, although it is > so old at this point that any advice there should be considered suspect. > > Are you volunteering to give it an overhaul? :)
Let me chime in. "I'm not sure how much of a site Mason needs going forward" I have found the documentation lacking. I am in the middle of building a site and every step of the way is a struggle. I find myself digging into code - Mason, Moose, Plack/PSGI, various plugins, ... - just to figure out how to do basic, simple things. Mason 2 may look a lot like Mason 1, but it is actually a very different beast. I should not have to dissect someone else's code to figure out something that could be documented. The Mason book was a godsend for Mason1, even though it quickly became out of date, it never became obsolete, and I still use it today. I have several copies, in fact. This is not to say that I am unappreciative of the work done by Jonathan and others. It is far better to use a well thought out framework, even having to struggle each step of the way, than to invent something myself, which would no doubt be less polished and take much longer. I think a community effort, like a wiki would be a terrific idea. Some examples of things I have struggled with that I could have added to a wiki, or would have been ecstatic to find on a wiki: 1) Different configurations for the web server side. How do I make this work with: - Apache / mod_perl (for production) - Apache /Fast CGI (for production) - Standard CGI (for development or servers I cannot change significantly) - other servers such as AOL, etc. Sample configurations which have been tested to work would be great. In my case, I had to write custom CGI wrappers/drivers and set up mod_rewrite. I know others could benefit from what I learned, just as I could have if someone else did it before me. 2) The current documentation states simply that some things have been removed, like <%shared> and says to use <%class> instead. Huh? First, from a psychological standpoint, they are different things and it takes a bit of a leap of faith to see how they relate. Sure, I can define an attribute and have it inherited from Base.mc to index.mc, but it will not share with some random a utility component that I call - at least I have not found a simple way of doing that. Examples that give the Mason 1 way of using shared, args, etc and the Mason 2 way would be hugely helpful. As a side note, Jonathan has been removing things like <%shared>, <%args>, %% and so on, because they are redundant. Perl is popular because of the multiple ways to do things. Experts will use <%class> to share and pass variables. Beginners can use <%shared> and %<args> because they are easy to understand. In the background, Mason translates it all to the same object code anyway. What's the harm? 3) How do I make Mason 2 recognize posted elements that have the same name and put them into an array in $.args? See Mason book pages 35-36 for the way it used to work - which was nice. I have not been able to get Mason 2 to do that, and I have found no documentation that lists how it can be done or even states that it cannot be done. Now, you may ask, why I would have a web form that has the different elements with the same name. Actually, this is how Javascript frameworks, like jQuery, send arrays, by default, so it is, in fact, a very useful feature. Yes, I realize this is more a Plack/PSGI issue, but since Jonathan made the decision to use Plack, I feel it is appropriate to address this. Let's face it, the majority of people are going to use Mason to generate web pages, so the web interface is an important item. 4) While it may be obvious to some, it is not obvious to everyone and certainly not beginners, what the data types of the special variables are. Example is $.args. What is this and how do I access the data in it? A simple statement in the documentation that $.args is a pointer / reference to a HASH would save a lot of unnecessary work and gnashing of teeth. 5) How can I have global variables? Can I make them read-only? Do not tell me globals are evil and I should be burned at the stake for suggesting them. Take a look at the object files Mason2 generates. Each and every one has 4 globals at the very top, including $m. Globals do have their place, if used correctly. An example is a site, that has a single included file for configuration - database access information, at the very minimum is needed, even if all other configurable options are stored in the database. It is inefficient to have every component read this file over and over again. Just store it in a read only global. 6) Moose is slow. So slow, that even the Moose people address it in their FAQ. What can I do to speed it up? What if I can only run on a standard CGI server that does not have mod_perl? Is it possible to use Mouse instead? Will Mason2 have a conniption? Are there things I can do with Mason so that it will not utilize some of the slower Moose features? I could go on and on, but I am not trying to get answers to these questions - most I have already figured out. But my knowledge does not help the next guy. While the Moose documentation is a bit more voluminous than Mason, neither compares to a Wiki or the Mason book. Also, I noticed that with Mason 1, it was easy enough to pick up, that a lot of people used it and the list had a lot of traffic. Traffic on the list has dropped to a tiny trickle since Mason2 came out and I think that is unfortunate. In my mind, that means one of two things: Mason 2 is so easy that no one has any questions about it, or it is so difficult, that people try it and quickly get frustrated and give up, moving on to the likes of PHP and such. I suspect it is the latter. I welcome any and all comments. Paul Wallingford ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
