On Mon, Apr 3, 2017 at 12:53 AM, iaw4 <[email protected]> wrote:

> my webapp needs simplicity and understandability/maintainability by
> non-MVC people.  it is not a full-time venture, but will be written once,
> then not looked at for years, then tinker with by someone else, etc.  my
> planned controller-view design is not universal, but it suits my particular
> project needs.  see, I have many, many URLs, each with short code and short
> template.
>

Depending how short, you might want to skip template files and just use
inline
<http://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Rendering-inline-templates>
.


> Thus, combining each URL into its small code bundled with its template is
> very appealing.
>

You can put templates in Controller and make your app find them by
adjusting the classes attribute in renderer
<http://mojolicious.org/perldoc/Mojolicious/Renderer#classes>.
You can also use Mojo::Loader::data_section
<http://mojolicious.org/perldoc/Mojo/Loader#data_section> in your
Controller and render:

package MyApp::Controller::Example;
use Mojo::Base 'Mojolicious::Controller';

use Mojo::Loader 'data_section';

# This action will render a template
sub welcome {
  my $self = shift;

  # Render template "example/welcome.html.ep" with message
  $self->render(inline => data_section(__PACKAGE__, 'welcome.html.ep'), msg
=> 'Welcome to the Mojolicious real-time web framework!');
}

1;

__DATA__

@@ welcome.html.ep
HI <%= $msg %>


> the M-Lite is too lite for me (which does keep code and templates together
> [good], albeit in ONE GIANT file [bad]), the M structure is too heavy---and
> although I have read "growing" a few times, it isn't fully clear to me.
>  there is a lot of magic there.  (I also don't have a web designer, so
> keeping the view separate is less important to me.)  I need the
> Mojolicious::Medium---each URL containing its controller and view in one
> file each, and each URL just pulls in from model.pm whatever model
> aspects that it needs.
>
> I had seen the helper functions in the (very nice) tutorial, too, but it
> does not seem nice/practical to transform every single model by hand into a
> helper function. or is there a way to instruct M to helper-ize a hundred
> functions?
>

package main;
use Mojolicious::Commands;
Mojolicious::Commands->start_app('MyApp');

package MyApp;
use Mojo::Base 'Mojolicious';
sub startup {
  my $self = shift;
  $self->helper(model => sub { state $model = MyApp::Model->new });
  $self->routes->get('/sub1')->to('example#sub1');
  $self->routes->get('/sub2')->to('example#sub2');
  $self->routes->get('/sub3')->to('example#sub3');
}

package MyApp::Model;
use Mojo::Base -base;
sub sub1 { join ',', map { $_*1 } @_[1..$#_] }
sub sub2 { join ',', map { $_*2 } @_[1..$#_] }
sub sub3 { join ',', map { $_*3 } @_[1..$#_] }

package MyApp::Controller::Example;
use Mojo::Base 'Mojolicious::Controller';
use Mojo::Loader 'data_section';
sub sub1 { shift->render(inline => data_section(__PACKAGE__,
'sub1.html.ep')) }
sub sub2 { shift->render(inline => data_section(__PACKAGE__,
'sub2.html.ep')) }
sub sub3 { shift->render(inline => data_section(__PACKAGE__,
'sub3.html.ep')) }
__DATA__
@@ sub1.html.ep
In sub1, <%= model->sub1(1, 2, 3) %>
@@ sub2.html.ep
In sub2, <%= model->sub2(1, 2, 3) %>
@@ sub3.html.ep
In sub3, <%= model->sub3(1, 2, 3) %>

If you can pare down a sample of your app, perhaps we can help you with a
better design.  I can assure you that Mojolicious is neither too Lite nor
too Heavy and I can assure you that helpers are quite nice and practical.
Mojolicious will definitely make your life easier -- now during development
with hundreds of routes and in the far future when you come back to make
some changes and need to understand what you did years ago.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Reply via email to