Menu
▾
▴
cgi-prototype-users — the general mailing list for CGI::Prototype
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(6) |
Jun
(13) |
Jul
(3) |
Aug
(30) |
Sep
(42) |
Oct
(12) |
Nov
|
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <me...@st...> - 2005-08-11 15:03:52
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes: A> Ok, so I=A2d like to dive in there and get the bits moving right A> now, but I don=A2t want to step on any toes, particularly with A> architectural (more or less) decisions like this one. How are we A> going to be handling issues like this one? I've checked in the current releases to "dist/*" in the CVS. If you are proposing a separate release, feel free to start another leg. If you are thinking that the release currently called CGI-Prototype should be altered, we can talk about making the changes directly there. Let's settle on the naming first... :) --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl trainin= g! |
|
From: A. P. <pag...@gm...> - 2005-08-11 13:03:21
|
* A. Pagaltzis <pag...@gm...> [2005-08-11 01:40]:
> So I think that rather than attempting to separate state
> deduction and mapping entirely, it would be enough to factor
> out the mapping into a common base and reuse that. As always,
> loads of slots make the job pretty smooth.
Ok, so I’d like to dive in there and get the bits moving right
now, but I don’t want to step on any toes, particularly with
architectural (more or less) decisions like this one. How are we
going to be handling issues like this one?
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: A. P. <pag...@gm...> - 2005-08-11 06:45:46
|
* Randal L. Schwartz <me...@st...> [2005-08-11 08:35]:
> My phrasing is "biased toward TT (Randal's favorite), but any
> templator can be chosen insteasd".
Okay then; I twiddled it to closely match that phrasing.
Note that I’ve made the file group-writable, so whoever of you
guys wants to change something there can go right ahead.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: <me...@st...> - 2005-08-11 06:26:53
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes: A> Heh, thanks. And well, CGIP *does* integrate TT by default, after A> all. But I added a clause saying that TT is optional =D0 that A> better? My phrasing is "biased toward TT (Randal's favorite), but any templator can be chosen insteasd". --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl trainin= g! |
|
From: A. P. <pag...@gm...> - 2005-08-11 04:12:03
|
* Terrence Brannon <ba...@me...> [2005-08-11 04:50]: > Plain nothing! That's a very nice page. I use CGIP without > Template Toolkit, so I dont like that part of the description. Heh, thanks. And well, CGIP *does* integrate TT by default, after all. But I added a clause saying that TT is optional – that better? > > cribbed together from the Randallâs and your POD, and > > corrected the project description (CGIP is not a template > > system and it does not use a database). > > OMG. I hope I didnt write something that off-base. Write, not exactly, but it was categorized as templating system and said that it used Perl/DBI as database environment. (It’s true that one would likely use DBI for database apps written with CGIP, but CGIP itself has nothing to do with that.) I was kind of surprised to find those bits in the profile. Anyway, it’s fixed. Regards, -- Aristotle “If you can’t laugh at yourself, you don’t take life seriously enough.” |
|
From: Terrence B. <ba...@me...> - 2005-08-11 02:42:11
|
"A. Pagaltzis" <pag...@gm...> writes: > * Terrence Brannon <ba...@me...> [2005-08-07 23:30]: >> I have added Aristotle (sf.net id: apag) as a developer with >> plenty of liberal admin rights to the whole project â let me >> know if you need more. > > Okay, Iâve gone in and put up a plain homepage Plain nothing! That's a very nice page. I use CGIP without Template Toolkit, so I dont like that part of the description. > cribbed together from the Randallâs and your POD, and corrected > the project description (CGIP is not a template system and it does > not use a database). OMG. I hope I didnt write something that off-base. -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. |
|
From: A. P. <pag...@gm...> - 2005-08-10 23:29:05
|
* Randal L. Schwartz <me...@st...> [2005-08-07 18:15]: > Cool. Ok, great, then I’ll keep working on it. > Right now, my thoughts are that Hidden is actually doing two > different things: > > 1) Figuring out the state (from hidden fields, as named) > 2) Mapping the state to classes (autoloading based on a prefix for the > class) Don’t forget the template location bits in #2. Looking at the source, only `render_enter`, dispatch` and `config_state_param` pertain to #1 at all. The rest is all neutral. I am thinking that the way to do this would be to pull all the other bits into CGI::Prototype::Simple, then derive from that in ::Simple::Hidden or ::Simple::PathInfo. > I'd like to refactor Hidden so that the pieces are separate > mixins, so that the state tracking and the state-to-class > mapping policy are independently reusable. Your code would > then provide an alternative for each of those (state via URL, > mapping via explicit table). The mapping is not entirely extricable from the state vehicle – I need an explicit table for ::PathInfo because URLs look like “/edit/post/261” or “/edit/user/ap” or “/user/ap”, and so the pathinfo parser needs a means to know which part is the mode and which is the positional parameters. But that’s just a matter of refactoring `name2page` to call a bunch of callbacks at the right points, and then it could provide for basically any mapping scheme whatsoever. I’d already been working on that, in fact. So I think that rather than attempting to separate state deduction and mapping entirely, it would be enough to factor out the mapping into a common base and reuse that. As always, loads of slots make the job pretty smooth. Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming” |
|
From: A. P. <pag...@gm...> - 2005-08-10 23:08:05
|
* Terrence Brannon <ba...@me...> [2005-08-07 23:30]: > I have added Aristotle (sf.net id: apag) as a developer with > plenty of liberal admin rights to the whole project – let me > know if you need more. Okay, I’ve gone in and put up a plain homepage cribbed together from the Randall’s and your POD, and corrected the project description (CGIP is not a template system and it does not use a database). Now back to the code… Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming” |
|
From: Terrence B. <ba...@me...> - 2005-08-08 02:39:47
|
me...@st... (Randal L. Schwartz) writes: >>>>>> "Terrence" == Terrence Brannon <ba...@me...> writes: > > Terrence> I have added Aristotle (sf.net id: apag) as a developer with > Terrence> plenty of liberal admin rights to the whole project - let me > Terrence> know if you need more. I couldn't find Randal Schwartz in > Terrence> the sf.net user list and someone has the name merlyn > Terrence> already. > > I'm "sourcemerlyn" there. added: https://sourceforge.net/projects/cgi-prototype/ |
|
From: <me...@st...> - 2005-08-07 21:40:22
|
>>>>> "Terrence" == Terrence Brannon <ba...@me...> writes: Terrence> I have added Aristotle (sf.net id: apag) as a developer with Terrence> plenty of liberal admin rights to the whole project - let me Terrence> know if you need more. I couldn't find Randal Schwartz in Terrence> the sf.net user list and someone has the name merlyn Terrence> already. I'm "sourcemerlyn" there. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: Terrence B. <ba...@me...> - 2005-08-07 21:22:22
|
me...@st... (Randal L. Schwartz) writes: >>>>>> "A" == A Pagaltzis <pag...@gm...> writes: > > A> Now my question is: should I put this on CPAN, or should I leave > A> the space to an âofficialâ version? Or should I just post it > A> here, maybe? If I put this on CPAN myself, what should I put in > A> the AUTHOR and COPYRIGHT & LICENSE sections of the POD? There is > A> so little code in there that the notion of authorship is a bit > A> ridiculous either way, but I also copied several pages of POD > A> that I can hardly claim authorship of. > > Well, if we create the SF archive, this can stay one or two distros. > I'd actually like to see separate distros like: I have added Aristotle (sf.net id: apag) as a developer with plenty of liberal admin rights to the whole project - let me know if you need more. I couldn't find Randal Schwartz in the sf.net user list and someone has the name merlyn already. Right now, it looks like Aristotle needs the privs more than Randal, but as soon as I get his name, I will heap on lots of privs for him as well. Yes, as soon as this PathInfo baby gets uploaded, I can de-Mason-ize a site of mine with the greatest of ease :) -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. |
|
From: <me...@st...> - 2005-08-07 16:07:41
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes: A> I just don=E2=80=99t want to step on Randalls=E2=80=99s toes in case he= =E2=80=99s already A> done this =E2=80=93 but I also have very specific ideas about how to do A> this and a CPAN directory longing for something to put in it. :-) And no, I have the idea to do it, but not the immediate motivation or time. :( Glad to see someone else is finding the framework useful. --=20 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl trainin= g! |
|
From: <me...@st...> - 2005-08-07 16:07:09
|
>>>>> "A" =3D=3D A Pagaltzis <pag...@gm...> writes:
A> and hi Randall in particular. I have a working version of this,
A> largely derived from ::Hidden for consistency in slot names. (It
A> also let me copy 95% of the POD verbatim. Writing documentation
A> is easy when it=E2=80=99s already done for you. *g*)
Cool.
A> It has a somewhat distinct personality in that it wants an
A> explicit list of page names to validate (I=E2=80=99d rather prefer if
A> ::Hidden worked the same way =E2=80=93 I like my code hardwired for =E2=
=80=9Cno
A> surprises ever possible=E2=80=9D) and works slightly differently in a few
A> minor aspects. But by and large a well-written ::Hidden app would
A> translate to a ::PathInfo one with almost no changes.
Right now, my thoughts are that Hidden is actually doing two different
things:
1) Figuring out the state (from hidden fields, as named)
2) Mapping the state to classes (autoloading based on a prefix for the clas=
s)
I'd like to refactor Hidden so that the pieces are separate mixins, so
that the state tracking and the state-to-class mapping policy are
independently reusable. Your code would then provide an alternative
for each of those (state via URL, mapping via explicit table).
As usual, my time is limited, but if someone wants to go into more
thoughts on that, I'm willing to discuss it. I'm also looking at
moving my sources to SF so that I can have more committers.
A> I=E2=80=99ve also added a little twist so that =E2=80=9Cfoo.cgi/bar/42=
=E2=80=9D will
A> dispatch to =E2=80=9CMy::App::bar=E2=80=9D and set the =E2=80=9Cpage_id=
=E2=80=9D slot to 42 in
A> the process. (The slot defaults to undef.) This is very handy for
A> cruft-free, clean URLs.
Nice.
A> Now my question is: should I put this on CPAN, or should I leave
A> the space to an =E2=80=9Cofficial=E2=80=9D version? Or should I just pos=
t it
A> here, maybe? If I put this on CPAN myself, what should I put in
A> the AUTHOR and COPYRIGHT & LICENSE sections of the POD? There is
A> so little code in there that the notion of authorship is a bit
A> ridiculous either way, but I also copied several pages of POD
A> that I can hardly claim authorship of.
Well, if we create the SF archive, this can stay one or two distros.
I'd actually like to see separate distros like:
CGI::Prototype
CGI::Prototype::Hidden (mixin for param->state)
CGI::Prototype::Autoload (mixin for state->class via autoload)
CGI::Prototype::Pathinfo (mixin for info->state)
CGI::Prototype::$mumble (mixin for state->class via $mumble)
etc. Or maybe even go down one layer... where
CGI::Prototype::GetState::$mumble is for all state determiners, and
CGI::Prototype::DoState::$mumble is for all state mappers. I hate those
names, but I hope the idea is clear.
--=20
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl trainin=
g!
|
|
From: Terrence B. <ba...@me...> - 2005-08-03 19:47:43
|
"A. Pagaltzis" <pag...@gm...> writes: > * Terrence Brannon <ba...@me...> [2005-08-03 20:15]: >> If you put it on CPAN and it is based on hidden, then perhaps >> it should be CGI::Prototype::Hidden::PathInfo? >> >> I never could figure out Hidden, I use the vanilla >> CGI::Prototype for everything. > > > In any case, ::Hidden::PathInfo is not the right name. I donât > inherit from ::Hidden and the code has nothing to do with any > state parameter. good point. |
|
From: A. P. <pag...@gm...> - 2005-08-03 18:46:38
|
* Terrence Brannon <ba...@me...> [2005-08-03 20:15]:
> If you put it on CPAN and it is based on hidden, then perhaps
> it should be CGI::Prototype::Hidden::PathInfo?
>
> I never could figure out Hidden, I use the vanilla
> CGI::Prototype for everything.
Hmm, I found it extremely straightforward. Just read the code, in
the worst case, and you’ll understand how it works. It’s just a
minor collection of shortcuts that saves you from setting up the
same scaffolding over and over.
In any case, ::Hidden::PathInfo is not the right name. I don’t
inherit from ::Hidden and the code has nothing to do with any
state parameter.
I just don’t want to step on Randalls’s toes in case he’s already
done this – but I also have very specific ideas about how to do
this and a CPAN directory longing for something to put in it. :-)
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: Terrence B. <ba...@me...> - 2005-08-03 18:05:10
|
"A. Pagaltzis" <pag...@gm...> writes: > I have a working version of this, > largely derived from ::Hidden for consistency in slot names. > Now my question is: should I put this on CPAN, or should I leave > the space to an âofficialâ version? If you put it on CPAN and it is based on hidden, then perhaps it should be CGI::Prototype::Hidden::PathInfo? I never could figure out Hidden, I use the vanilla CGI::Prototype for everything. If the decision is to post at sf.net, just tell me what I need to do on the sourceforge site to set you up since I admin this list and sf.net site. |
|
From: A. P. <pag...@gm...> - 2005-08-03 03:01:30
|
Hi all,
and hi Randall in particular. I have a working version of this,
largely derived from ::Hidden for consistency in slot names. (It
also let me copy 95% of the POD verbatim. Writing documentation
is easy when it’s already done for you. *g*)
It has a somewhat distinct personality in that it wants an
explicit list of page names to validate (I’d rather prefer if
::Hidden worked the same way – I like my code hardwired for “no
surprises ever possible”) and works slightly differently in a few
minor aspects. But by and large a well-written ::Hidden app would
translate to a ::PathInfo one with almost no changes.
I’ve also added a little twist so that “foo.cgi/bar/42” will
dispatch to “My::App::bar” and set the “page_id” slot to 42 in
the process. (The slot defaults to undef.) This is very handy for
cruft-free, clean URLs.
I’ve pondered doing more extensive URL parsing than what I
currently have, based on the fact that the list of valid page
names is known; but I couldn’t think of good, simple conventions
for the meaning of the addition path segments, so I left it out
for the time being. I think the best course of action would be to
pass those to a slot so the user can define any behaviour they
desire, and leave the default implementation of that slot empty.
Now my question is: should I put this on CPAN, or should I leave
the space to an “official” version? Or should I just post it
here, maybe? If I put this on CPAN myself, what should I put in
the AUTHOR and COPYRIGHT & LICENSE sections of the POD? There is
so little code in there that the notion of authorship is a bit
ridiculous either way, but I also copied several pages of POD
that I can hardly claim authorship of.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
|
|
From: Potozniak, A. <acs...@ub...> - 2005-07-21 19:08:06
|
Fellow CGI::Prototypers:
=20
I have run into a strange problem when using C::P::Mecha.
=20
My prototype page has a form on it which has an input type of 'file' and
the form has an enctype of multipart/form-data.
Now when I upload a file via the web everything works perfectly fine,
but when I try to simulate this with C::P::Mecha it seems that I have to
hit '^C' to get the submission of the file to complete, otherwise the
test script hangs. Now there are other form submissions that I am doing
in my test script that work perfectly with out this intervention.
=20
A couple of thoughts that I have: =20
=20
Maybe (for some odd reason) ^C causes the upload stream to terminate
thus finishing off the form submission.
There might be some other unknown issue with file uploading with
mech that I'm unaware of.
=20
Here is some sample code:
=20
$m->field('file_name', '/some/file');
$m->click('upload'); #This is where it hangs
=20
Thank you for your help,
~~Andrew
=20
010100000110111101110100011011110111101001101110011010010110000101101011
Andrew Potozniak
Administrative Computing
Programming Intern
State University of New York at Buffalo
010100000110111101110100011011110111101001101110011010010110000101101011
=20
"All that is visible must grow beyond itself; extend into the realm of
the invisible." (TRON 1982)
=20
|
|
From: Andrew G. <ag...@bu...> - 2005-07-01 20:44:18
|
Shortly after posting this, I thought of another, simpler solution (perhaps along the lines of what you are suggesting), which is a little more explicit and maybe a little easier to understand and support. But I wanted to see if I received any feedback before muddying the waters by answering my own question. It should be (theoretically) simple enough to create a page module for the page that borrows functionality and simply add the module of the class I need the functionality from to the use base statement, a la: use base qw( Project2::App::borrowed_page Project1::App ); Then as long as I put hooks into my primary methods of Project2::App::borrowed_page I can easily reuse and modify the functionality. That said, and I don't purport to be an OO expert, my understanding of CGI::Prototype is that it is intended to be an OO framework, which means that it inherently makes sharing functionality easier. In OO perl, this is still just through the use of use base statements, and my proposal was to augment the framework by having the module perform that use base for me automagically. Andrew On 7/1/05 1:24 PM, "Terrence Brannon" <ba...@me...> wrote: > Andrew Gianni <ag...@bu...> writes: > >> can you suggest a better way to share >> pages and functionality between applications? >> > > This is not a sarcastic response, but it is really what I think about > this situation. Sharing *functionality* should be the province of > vanilla Perl. Perl has a wealth of re-use/sharing mechanisms within > itself, with require and use being the most obvious ones... > > It does not matter what one is doing in Perl - functionality re-use > occurs via subroutines and modules. I don't think that CGI/mod_perl > should be any different and for me, it is not. Neither Mason nor tt2 > nor CGI::Prototype nor anything else can do a better job than vanilla > Perl at re-using *functionality*. > > Now by re-using part of the display output (what you refer to as > "pages") depends critically on what you are doing to render HTML. For > me, as an HTML::Seamstress proponent, it would be a simple matter of > having the HTML somewhere it can be opened and processed and popped > inline in a larger document. But all the dynamic HTML toolkits have > means of re-using page data - tt2 has INCLUDE, WRAPPER (I think those > are right, I dont use tt2), and mason has components. > > Cheers, > Terrence Brannon > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > cgi-prototype-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users -- Andrew Gianni Administrative Computing Services State University of New York at Buffalo 215 Millard Fillmore Academic Complex Amherst, NY 14261 (716) 645-3587x7124 |
|
From: Terrence B. <ba...@me...> - 2005-07-01 17:25:18
|
Andrew Gianni <ag...@bu...> writes: > can you suggest a better way to share > pages and functionality between applications? > This is not a sarcastic response, but it is really what I think about this situation. Sharing *functionality* should be the province of vanilla Perl. Perl has a wealth of re-use/sharing mechanisms within itself, with require and use being the most obvious ones... It does not matter what one is doing in Perl - functionality re-use occurs via subroutines and modules. I don't think that CGI/mod_perl should be any different and for me, it is not. Neither Mason nor tt2 nor CGI::Prototype nor anything else can do a better job than vanilla Perl at re-using *functionality*. Now by re-using part of the display output (what you refer to as "pages") depends critically on what you are doing to render HTML. For me, as an HTML::Seamstress proponent, it would be a simple matter of having the HTML somewhere it can be opened and processed and popped inline in a larger document. But all the dynamic HTML toolkits have means of re-using page data - tt2 has INCLUDE, WRAPPER (I think those are right, I dont use tt2), and mason has components. Cheers, Terrence Brannon |
|
From: Andrew G. <ag...@bu...> - 2005-06-28 20:11:43
|
I'm starting to run into situations where I have (or will soon have)
multiple applications that need to occasionally share pages, or at least
some functionality. I was thinking that a good way of doing this would be to
allow the config_class_prefix method (CGI::Prototype::Hidden) return an
array rather than just a scalar. That way, if I was working on project one,
instead of just:
sub config_class_prefix{
return 'Project1::App';
}
I'd like to be able to do something like this:
sub config_class_prefix{
return qw( Project1::App Project2::App );
}
Then I could call name_to_page or shortname on pages from either project.
Does this sound like a good idea, or can you suggest a better way to share
pages and functionality between applications?
Andrew
--
Andrew Gianni
Administrative Computing Services
State University of New York at Buffalo
215 Millard Fillmore Academic Complex
Amherst, NY 14261
(716) 645-3587x7124
|
|
From: Andrew G. <ag...@bu...> - 2005-06-28 13:51:02
|
Generally, here's how I've dealt with it:
Make your link on the welcome page something along the lines of:
<a href="_state=login'>Log In</a>
In login.pm you'll need to cover both the case where they're coming to the
login page via a link (hint: make sure the username and password params
aren't set or make sure that only _state is set), and the case where the
username and password are set and should be processed.
Andrew
On 6/28/05 8:59 AM, "John S J Anderson" <gen...@ge...> wrote:
>
> I'm just starting to try to wrap my head around C::P::Hidden (or vice
> versa), so it's entirely possible I'm not thinking about this properly
> -- but I can't figure out the Right Way to link to a non-default page.
>
> Suppose I have two "pages": Welcome and Login. (A "page" is a
> combination of a .pm and a .tt; there's only one actual CGI.) I have
>
> sub config_default_page { "Welcome" }
>
> in the base My::App.pm.
>
> In Welcome.tt, I want to have an <a> element where the href attribute
> takes me to the Login page. It seems like I have two options:
>
> 1) use an onClick attribute to manipulate the hidden _state field to
> change its value to 'Login'
> 2) encode '?_state=Login' into the URL in the href attribute (or various
> other schnanigans with specifying some state in the URL -- use
> 'state=login' and switch on that in the respond_per_page() in the
> base class, for example)
>
> Is that pretty much accurate or is there some slickness I'm missing?
>
> thanks,
> john.
--
Andrew Gianni
Administrative Computing Services
State University of New York at Buffalo
215 Millard Fillmore Academic Complex
Amherst, NY 14261
(716) 645-3587x7124
|
|
From: <me...@st...> - 2005-06-28 13:23:31
|
>>>>> "Randal" == Randal L Schwartz <me...@st...> writes: Randal> Then I can say: Randal> [% WRAPPER link state = "Login" %]Login![% END %] No, that's not right. I have to do something with a href =. Not sure how I was using that here. :) Randal> ------------------------------------------------------- Randal> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies Randal> from IBM. Find simple to follow Roadmaps, straightforward articles, Randal> informative Webcasts and more! Get everything you need to get up to Randal> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click Randal> _______________________________________________ Randal> cgi-prototype-users mailing list Randal> cgi...@li... Randal> https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: <me...@st...> - 2005-06-28 13:16:53
|
>>>>> "john" == John S J Anderson <gen...@ge...> writes:
john> 2) encode '?_state=Login' into the URL in the href attribute (or various
john> other schnanigans with specifying some state in the URL -- use
john> 'state=login' and switch on that in the respond_per_page() in the
john> base class, for example)
I've used this, and recommend this. In the fictional
CGI::Prototype::Cookbook, I have this:
USE selfcgiurl = url(self.CGI.url({ path => 1 }));
BLOCK link;
# [ state = "new state" ] (defaults to current state)
# [ other = { ... } ] (additional URL params)
csp = self.config_state_param;
DEFAULT state = self.param(csp);
DEFAULT other = {};
other.$csp = state;
selfcgiurl(other);
END;
Then I can say:
[% WRAPPER link state = "Login" %]Login![% END %]
Note that this requires config_state_param to not begin with an
underscore or dot, thanks to some odd interactions with TT's
restrictions.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
|
|
From: John S J A. <gen...@ge...> - 2005-06-28 13:00:21
|
I'm just starting to try to wrap my head around C::P::Hidden (or vice
versa), so it's entirely possible I'm not thinking about this properly
-- but I can't figure out the Right Way to link to a non-default page.
Suppose I have two "pages": Welcome and Login. (A "page" is a
combination of a .pm and a .tt; there's only one actual CGI.) I have
sub config_default_page { "Welcome" }
in the base My::App.pm.
In Welcome.tt, I want to have an <a> element where the href attribute
takes me to the Login page. It seems like I have two options:
1) use an onClick attribute to manipulate the hidden _state field to
change its value to 'Login'
2) encode '?_state=Login' into the URL in the href attribute (or various
other schnanigans with specifying some state in the URL -- use
'state=login' and switch on that in the respond_per_page() in the
base class, for example)
Is that pretty much accurate or is there some slickness I'm missing?
thanks,
john.
--
The test of a first-rate intelligence is the ability to hold two
opposed ideas in mind at the same time and still retain the ability to
function. One should, for example, be able to see that things are
hopeless and yet be determined to make them otherwise. - F. Scott Fitzgerald
|
1 message has been excluded from this view by a project administrator.
