Re: [Catalyst] Suggestions for CatalystX::Installer

2008-05-17 Thread Paul Cain
I have created a rough specification based on all of this input. It is
a bit rough right now, but I will try to clean it up when I get more
time. This week is the week of my final exams, therefore I was busy.

Here is the specification(if you are too lazy to read the whole thing,
skip to the footnotes for points of conversation). Questions,
comments, and more input/feedback are welcome:


*Synopsis*
Create a web application that provides a cross-platform generic GUI
for setting up Catalyst applications.

*Project Details*
For CatalystX::Installer, the Movable Type setup wizard is used as an
inspiration for its design. The main new idea of this approach is that
the program will provide a generic GUI that works with most common
use-cases for Catalyst applications, and provides a framework for
extension for specialist use-cases.
This approach frees the Catalyst developers from having to design a
setup wizard for their application(with the possible exception of some
special cases) while also freeing the user from the hassle of having
to use a different(or no) install wizard for each Catalyst application
that he or she installs.

#What The Developer Does

$ catalyst MyApp
$ cd MyApp
$ catalystx-installer [options]

The first command creates the skeleton of the Catalyst application,
the second command switch to the root directory of that Catalyst
application, and the third command creates  script/myapp_setup.pl and
handles any special options.

 Where script/myapp_setup.pl would contain a stand-alone server
similar to script/myapp_server.pl. The administrator(person installing
the Catalyst application) could then connect to this server and use
the GUI to apply the configuration information[1] when the application
is installed on a server. The application developer could also
customize this based on the requirements of his or her application. I
would create a set of APIs that wrap around HTML::FormFu to make this
process as simple as possible. For example, if the application
developer wanted to allow users to run SQL commands(from a file) on a
SQLite database, he or she could do something like this[2].

my $sql_commands=CatalystX::Installer::Controller-new();
$sql_commands-set_type('Entry');
$sql_commands-set_action(sub{
my ($self, $c,$database,$sql_file);
system sqlite3 $database  $sql_file;
});

This would allow the developer to easily customize the installer for
his or her applications. A link to script/myapp_setup.pl could
possibly be placed into the root directory during make dist.  The
developer could place post-setup in a directory called
'post_t/'.Lastly, the developer could archive the application for
distribution.



#What The User Does

When the user(server administrator) downloads the applications, they
first extract it from the archive, switches to directory, and then
types the command[3]:

$ perl script/myapp_setup.pl

First, it scans for dependencies with Module::ScanDeps, and adds any
dependencies not already found in Makefile.PL to Makefile.PL.  It then
runs through the installation scripts while keeping the user informed
of its progress:

$perl Makefile.PL
$make
$make test
$make install

 If  the tests in 'make test' pass and 'make install' complete
successfully, it will prompt the user to either enter a password or
use a randomly generated password with which the GUI setup can be
accessed(the user can change the password in the GUI setup). The user
can then access this server either from the local machine or a remote
one, as long as they are using web browser capable of entering
information into web forms. The password exists to prevent
unauthorized access to myapp_setup.pl, it is stored in an encrypted
location, and it is required for all subsequent runnings of
myapp_setup.pl. The connection will also be encrypted with SSL/TLS in
order to assure the safety of all data sent. When the GUI setup is
complete, it will ask the user if they want the setup program to
create a script that can be used to automatically enter the data that
they just entered into the GUI setup program. This allows a user to
clone a setup for multiple systems and of course a password is still
required. Also, the script, if created, will only be readable by the
user who created it.

The GUI setup will be (possible) be organized into four sections:
Login, Model, Controller, and View. Each of these sections can also
have sub-sections.

CatalystX::Installer can be used for more than just installation; it
can also be used to reconfigure an application that has already been
installed. For example, if the user were to run myapp_setup.pl again,
they could change the options they set up the first time.
myapp_setup.pl would then save a backup copy of the original
configuration file(s), and create new ones with the new options[4].

There are of course some uncertainties for this application. One of
the main foreseeable problems for this application will be making the
GUI generic enough where works for all programs, 

Re: [Catalyst] flash and Template::Stash::ForceUTF8

2008-05-17 Thread Bill Moseley
On Sat, May 17, 2008 at 10:57:36AM +0300, Angel Kolev wrote:
 Hello, group.
 I use 'flash' to share some params across the sessions and then redirect.
 sub edit : Local {
my ( $self, $c) = @_;
my $edit = $c-request-params-{section}|| $c-flash-{section}|| ;


$c-flash-{section} ='Pricing';
$c-res-redirect($c-uri_for('/clients/edit')); # redirect to the 
 same place but with different params
 }
 I use Template::Stash::ForceUTF8 and get following error when i try to 
 fetch $edit:
 
 undef error - flash takes a hash or hashref at 
 /usr/local/share/perl/5.8.8/Template/Stash/ForceUTF8.pm line 12

Are you sure you want ForceUTF8?  Doesn't that just force the utf8
flag?  If that's the case then I'd look more closely at why you have
non-decoded strings in variables and instead make sure your input is
decoded correctly when the data is fetched from outside your program.

If your templates are UTF8 then you can tell TT to decode the
templates automatically with ENCODING = 'UTF-8'.

I'd also be careful with flash as reading flash clears everything in
the flash, IIRC.  I tend to just delete $c-session-{foo}.

-- 
Bill Moseley
[EMAIL PROTECTED]


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/