Re: [Catalyst] mojomojo capability questions

[Dave Howorth]

Dennis Daupert wrote:
> A most impressive feature of MojoMojo is its hierarchical arrangement. That
> would allow us to create a document set for some given project comprised of
> a tree-structured set of pages.

Many technically-minded people see hierarchically structured
documentation as being well-ordered and neatly matching the system it is
describing. It turns out however that documentation is almost always
better written with a fairly flat structure with a strictly limited set
of levels (maybe 3 or perhaps 4). The structure in the software system
needs to be replaced by sequences in the documentation.

> If it were then possible to point to the
> parent document and export just that tree, that capability would weigh
> heavily in favor of MojoMojo. I've found mention of the capability of
> exporting the entire wiiki, but not of a selected tree-structure. Does that
> capability exist?

This seems like the solution driving the requirement. It sounds like
your requirement is to produce separate documentation for separate
projects. There are many ways to accomplish that.

> One absolute requirement: the wiki must be able to export pages to PDF. Our
> management would actually prefer exporting to Ms Word, but that's a bit of
> a stretch. I haven't seen any wiki so enabled.

You may find it useful to make an intermediate step. Export from the
wiki in some 'useful' format and then use word-processing or other
specialised document transformation software to reach your final target.
LibreOffice could export in Word format for example, or there are many
CPAN modules that could help.

___
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/

Re: [Catalyst] Catalyst, ExtJS and TT

[Dave Howorth]

Jean-Marc Choulet wrote:
> Hello,
> 
> I have a javascript file named EntrepriseWindow.js in root dir. It
> contains some TT code. I must add a extension (I renamed the file
> EntrepriseWindow.js) for it to work. Otherwise, it does not work :
> 
> sub EntrepriseWindow :Path('EntrepriseWindow.js') {
> 
> my ($self, $c) = @_;
> 
> $c->stash->{template} = 'EntrepriseWindow.js.tt';
> 
> $c->response->content_type('application/javascript');
> 
> }
> 
> I cannot write this ?
> 
> $c->stash->{template} = 'EntrepriseWindow.js';

Most frameworks that use TT have a mechanism to find template source
files based on their extension. In the case of Catalyst, see

http://search.cpan.org/~jjnapiork/Catalyst-View-TT-0.41/lib/Catalyst/View/TT.pm#TEMPLATE_EXTENSION

If you think about it, the file you want TT to process is *not* a .js
file, it's a file with some TT syntax in it that needs processing to
*become* a .js file. So it would be unhelpful if Catalyst tried to
TT-process real .js files and it's reasonable, IMHO, to have something
like a .js.tt extension.

___
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/

Re: [Catalyst] Using Progressive realms when username and password fields are all different

[Dave Howorth]

Will Crawford wrote:
> On 28 June 2012 23:12, Gavin Henry  wrote:
> ...
>> Thanks Tim. Yes, I know that but then the other two realms will fail
>> and that's the point of progressive. I want to call one ->authenticate
>> which tries all the realms I've defined in progressive_oauth.
> 
> Regrettably, the docs for the Password realm saith:
> 
> NOTE If the password_field is something other than 'password', you
> must be sure to use that same field name when calling
> $c->authenticate().
> 
> I'd call that a bug, personally - it certainly isn't intuitive that
> you can specify the field to use, but then have to remember it in all
> your calls to authenticate().
> 
> Not much can be done about that, though. Maybe someone can produce an adaptor?

Does something like this fix the problem?

--- Password.pm 2012-06-29 11:23:51.0 +0100
+++ Password-new.pm 2012-06-29 11:33:40.0 +0100
@@ -34,6 +34,14 @@
 sub authenticate {
 my ( $self, $c, $realm, $authinfo ) = @_;

+my $password_field = $self->_config->{'password_field'};
+if ($password_field ne 'password'
+and defined $authinfo->{password}) {
+   $authinfo = {%{$authinfo}};
+   $authinfo->{$password_field} = $authinfo->{password};
+   delete $authinfo->{password};
+}
+
 ## because passwords may be in a hashed format, we have to make
sure that we remove the
 ## password_field before we pass it to the user routine, as some
auth modules use
 ## all data passed to them to find a matching user...


___
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/

Re: [Catalyst] Re: Using model layers between Catalyst and DBIC

[Dave Howorth]

Bill Moseley wrote:
> That is, we want to allow $user->first_name, but not
> $user->search_related or $user->delete.
> 
> That requires writing new wrapper classes for every possible result -- not
> just mirroring DBIC's result classes but possibly many more because the new
> model might have multiple calls (with different access levels) for fetching
> user data.  That is, $user->email might work for some model methods that
> return a user but not methods called on the model.
> 
> Frankly, to me this seems like a lot of code and work and complexity just
> to prevent another developer from doing something stupid -- which we cannot
> prevent anyway.  And smart programmers can get at whatever they want,
> regardless.  Seems more risky to make the code more complex and thus harder
> to understand.  The cost/benefit ratio just doesn't seem that great.

You don't necessarily need new classes. You need to change existing
behaviours, so you could override methods. To prevent programmers doing
things, you don't need to make it impossible, just make it easy to see
when they are naughty. A log entry, or an audit record in the database,
or even peer review of the code, can all be sufficient to stop a
programmer calling delete. As long as they know they're not supposed to
call it! What's appropriate all depends on the application and your
circumstances, of course. JMHO.

> I suppose this is not unlike the many discussions about what to pass to the
> view.  Does the controller, for example, fetch a user object and pull the
> data required for the view into a hash and then pass that to the view?  Or
> does the controller just fetch a user object and pass that directly to the
> view to decide what needs to display?
> 
> I prefer just passing the object to the view.  The controller code is much
> cleaner and then when the view needs to change don't need to also change
> the controller.  And when there's a different view (like an API or moble )
> the same controller action can be used.

You might (re)read what Martin Fowler has to say about facades. It may
help you to firm up your own opinion, even if you disagree with him.

Cheers, Dave

___
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/

Re: [Catalyst] What are the best practices for using phrasebooks inCatalyst applications?

[Dave Howorth]

Octavian Rasnita wrote:
> It may work unless the site already needs to use I18N for real languages.

I think the solution in that case is to use a language tag something like

 en-US-x-my-private-tag-for-this-user


___
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/

Re: [Catalyst] Apache2 and mod_perl deployment issue

[Dave Howorth]

Adam Jimerson wrote:
> After looking into deploying under mod_fastcgi turns out the closest thing
> openSUSE ships with is mod_fcgid version 2.3.6

To find opensuse packages, the usual method is to search via
 or via equivalent search facilities in YaST.

Searching for 'fastcgi' turns up many packages, including
apache2-mod_fastcgi, which I think is what you would need (it's in the
Apache:Modules/openSUSE_12.1 repository, and I believe is also available
for earlier releases).

Cheers, Dave

___
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/

Re: [Catalyst] Catalyst::Controller:REST and JSON vs JSONP issue

[Dave Howorth]

James Spath wrote:
>> FWIW, IMHO the issue is better fixed in JSON::XS et al than in
>> Catalyst::Action::Serialize::JSON. I don't see why JSON can't always
>> encode the two problematic characters.
> 
> I suppose it could be in JSON::XS .. but JSON::XS is doing nothing
> wrong ... the two characters are perfectly valid JSON ... but they are
> NOT valid in JavaScript.

That's strictly true, but neither is it doing anything wrong by encoding
the two characters. From the spec :
  "Any character may be escaped.  If the character is in the Basic
   Multilingual Plane (U+ through U+), then it may be
   represented as a six-character sequence: a reverse solidus, followed
   by the lowercase letter u, followed by four hexadecimal digits that
   encode the character's code point."

And it's going against the spirit of the specification, which says, in
section 6 under Security considerations:
  "JSON is a subset of JavaScript".

It appears to be a simple oversight in the specification.

> Perhaps it could be an option in JSON::XS?

Well that would fit with TMTOWDTI but I'd suggest asking the world
whether anybody has a use case before adding the complication :)

Cheers, Dave

___
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/

Re: [Catalyst] moniker_map arg in app_create.pl

[Dave Howorth]

Tomas Doran wrote:
> 
> On 5 May 2011, at 16:27, matthew couchman (JIC) wrote:
> 
>> Sorry! It looks like I just had my arguments in the wrong order:
> 
> That was hella easy to miss (I at least had _no idea_).
> 
> A doc patch with an example to help other people avoid the same trap
> would be very welcome :)

It's a bit odd that DBIx::Class::Schema::Loader make_schema_at doesn't
produce an error or a warning when it doesn't find a table called
'PlantSpecies'.


___
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/

Re: [Catalyst] Sending Email from Page?

[Dave Howorth]

John M. Dlugosz wrote:
> On 3/27/2011 12:22 PM, Tomas Doran bobtfish-at-bobtfish.net
> |Catalyst/Allow to home| wrote:
>>
>> And I would say that sending an email is a state change, and behavior
>> of the application domain here.
> That's a stretch, because you can argue that any side-effect is a change
> of state to the universe at large and there happens to be no accessor to
> read the results of the change.  It clearly matches "side effect", not
> "state", unless you stretch the definition to make all side effects into
> state and lose all distinction.

 Sending an email isn't a side-effect or a state change, it's an
output. And the thing that sends it isn't a controller or a model or an
accessory, it's a View. Of course there may be specialized methods in
the model as well. 

___
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/

Re: [Catalyst] DBIC mailing list?

[Dave Howorth]

Octavian Rasnita wrote:
> From: "Bill Crawford" 
>> 2010/9/3 Octavian Rasnita :
>>> Has anyone any idea why I can't send messages to the DBIC mailing list
>>> anymore?
>>>
>> When you say "don't reach the list" is it possible you're not seeing
>> it because your mail client sees it as a duplicate of the sent message
>> which it's already stored elsewhere?
> 
> Nope, it is not possible, because it doesn't happend with other mail messages 
> sent to other mailing lists, like the current one, for example and my 
> messages just don't come back.
> 
> (And my office email address is hosted on our server and it doesn't block 
> self messages).

Also, if Octavian's messages were reaching the list, we would all have
seen them. I haven't for one.

Octavian, I suggest you contact the DBIC list admin. The address is at
the bottom of the mailman page listed at the end of al messages.

It sounds like either a blacklist error or misconfiguration of an
anti-spam feature like DKIM somewhere.

Cheers, Dave

___
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/

Re: [Catalyst] how to confirm before deleteing

[Dave Howorth]

Paul Falbe wrote:
> That works thank you very much.  Don't know how many google searchs I did
> trying to find that out!

> Rodrigo-51 wrote:
>> Paul, how about a javascript confirm() box?

... and if the user has Javascript disabled? 

Doh!

___
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/

[Catalyst] CSRF

[Dave Howorth]

There's an interesting paper on CSRF mentioned on slashdot today:


It mentions Catalyst along with some other frameworks and suggests a way
to build in CSRF-protection.

Cheers, Dave

___
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/

Re: [Catalyst] Catalyst site design drafts feedback thread

[Dave Howorth]

Matt S Trout wrote:
> Where possible, please reply with your feedback directly to this post

To add a little to themes that others have brought up; basically some
things to consider in the design.

I have old eyes too, and strong lenses, so I'm all for good size clear
fonts. It's also easier to read dark writing on a light background.
Sites with important content in light writing on a dark background put
me off, especially in fonts with thin, elegant strokes.

I never have my browser window the full width of my screen. I want to be
able to make use of whatever I'm seeing in the browser in some other
window at the same time. So I get very annoyed by sites that are
gratuitously wide and don't gracefully reshape if I change my browser width.

I also get annoyed by sites that don't cope well if I increase the font
size. Either bits of 'text' that don't change size (e.g. flash or
images), or text that overlaps images or other text, or that forces the
window wider.

Finally, I quite often browse with Javascript off, so menus or search
boxes that don't provide HTML fallback are irritating.

HTH, Dave

___
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/

Re: [Catalyst] Memory leak under FastCGI?

[Dave Howorth]

Matt S Trout wrote:
> On Fri, Apr 11, 2008 at 11:20:53AM -0400, Matt Pitts wrote:
>>> The accept() happens in the child in normal situations though, so the
>>> parent can't know how many requests a given child has handled without
>>> additional complication.
>> Yeap. My version of the "additional complication" is a lite IPC
>> messaging system using DBM::Deep. I override post_dispatch in the
>> children to send a message to the queue that says "I just finished
>> handling a request" and then the manager iterates the message queue
>> during each daemon loop and keeps track of each child's request count.
> 
> Yuck.
> 
> Seems much simpler to me to do something like:
> 
> Child1 hits request count, sends SIGUSR1 to proc manager, starts exiting
> 
> Manager sends SIGUSR1 to all other children
> 
> (child may take a while to clean up, exit happens somewhen)
> 
> Other children go into "must not die" mode
> 
> Manager spawns new child once it gets SIGCHLD
> 
> New child sends SIGUSR2 to proc manager once it's starting its accept()
> loop
> 
> Proc manager sends SIGUSR2 to all children to indicate they're allowed to
> die now if they want to
> 
> Seems a lot more unixy to me, and likely much less overhead as well.

Child1 starts the cycle, child2 & child3 receive SIGUSR1 and both soon
hit request limit (they're all fed by round-robin, perhaps). Manager
sends SIGUSR2. Both child2 and child3 send SIGUSR1 and die. Even if the
protocol is fixed to avoid this race I suspect there will be 'convoys'
unless some randomisation is introduced.

Can I suggest a different approach? The requirement is to make sure each
child dies regularly to avoid problems from memory leaks. So have the
manager just tell each child to die in turn based on a timer. Simple and
fixed overhead. It doesn't matter if children die 'too early' in light
load conditions.

Cheers, Dave

___
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/

Re: [Catalyst] Re: trouble with model->dbic resultset

[Dave Howorth]

A. Pagaltzis wrote:
> * Michael Higgins <[EMAIL PROTECTED]> [2007-12-05 22:40]:
>> Isn't that some general principle, you find the error just
>> after emailing a whole bunch of people?
> 
> Another effective [debugging] technique is to explain your
> code to someone else. This will often cause you to explain
> the bug to yourself. Sometimes it takes no more than a few
> sentences, followed by an embarrassed “Never mind. I see
> what’s wrong. Sorry to bother you.” This works remarkbly
> well; you can even use non-programmers as listeners. One
> university computer center kept a teddy bear near the help
> desk. Students with mysterious bugs were required to explain
> them to the bear before they could speak to a human
> counselor.
> 
> —Brian W Kernighan, Rob Pike, “The Practice of Programming”
> 
> Reportedly, this noticably reduced the load on the understaffed
> centre.

We had a teddy bear at one place I worked. I can testify first- and
second-hand that it worked well :)

Cheers, Dave

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

Re: [Catalyst] BBC's "Perl on Rails" nuttiness

[Dave Howorth]

>>> You have to remember that Siemens are responsible for ensuring the
>>> stability of the public facing infrastructure.
>>> This makes it important not to introduce new modules, or upgrade
>>> existing modules, without an extensive
>>> testing period to make sure it works with all existing applications. The
>>> trouble with this is that it is easier to
>>> keep stable (or work around existing known problems) by not installing
>>> anything new.
>>> 
>> Sure - but as I understand BBC is their client and this policy makes
>> the life of BBC programmers pretty miserable.  
>>   
> Yes, it does make for a pretty frustrating work environment
> sometimes and although Siemens should
> be working for the BBC it often feels like the other way around.
> 
> Seems poorly thought out.

There's one point that hasn't been stressed that I think is very
important. The problem isn't technical, it's commercial.

The BBC have outsourced some work to Siemens. It's certainly the case
that to maintain stability Siemens would need to do testing but I
imagine the main factor from their point of view is that *it provides
extra revenue*. I don't know about this contract but on another I'm
aware of they like nothing better than having the client request a new
feature :)

Without knowing the reasons why the BBC chose to outsource and the
contract details, it really isn't possible to say whether it's a
sensible arrangement. Sure it makes developers' lives more difficult,
but that's not the main goal to be optimized.

Cheers, Dave

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