in reply to Splitting long text for Template

I have an app where the shortened “preview” can be supplied by the article author or editor – so it might not be text from the beginning of the article. For me, that makes the preview a potential attribute of the article itself. (If there’s no supplied preview, I generate one by extracting text up to the first paragraph break after a length threshold.)

So the article has html and preview_as_html methods, and the template does something like:

[% IF article.has_preview %]
    [% article.preview_as_html %]
    <p class="readmore"><a href="[% article.uri %]">Read more…</a></p>
[% ELSE %]
    [% article.html %]
[% END %]

[download]

You could just as easily have the template output them both, with the full text hidden, and have your JS toggle between them.

This also shows how I handle the model/view distinction in this app. The article object that the template sees is considered “view support” code and is a wrapper around the object from the DB. I’m doing a conversion from MultiMarkdown → HTML inside the wrapper object. (Actually, it’s not quite as simple as that or I could do that in the template with the Template::Plugin::MultiMarkdown plugin.)

– Aaron
Preliminary operational tests were inconclusive. (The damn thing blew up.)

Replies are listed 'Best First'.
Re^2: Splitting long text for Template
by marto (Cardinal) on Feb 08, 2021 at 10:40 UTC

    "You could just as easily have the template output them both, with the full text hidden, and have your JS toggle between them."

    You can do this without JavaScript, which if you are concerned about not impacting those who browser without this enabled by default, which IIRC search engines also take into accounts.

[reply]
Re^2: Splitting long text for Template
by LanX (Saint) on Feb 08, 2021 at 14:48 UTC
    That's a nice idea.

    > The article object that the template sees is considered “view support” code

    Questions are:

    • Where is this code located?
    • How do you make the distinction to "controller support" Perl code?

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]

      Questions are:

      • Where is this code located?

      This is actually a pretty tiny app, so it’s actually in MyApp::Article, which loads the original from disk (not a DB). In a larger app I usually have a MyApp::View namespace for that stuff to go in.

      • How do you make the distinction to “controller support” Perl code?

      I’m not quite sure what you’re asking, so I’ll answer it two different ways. :)

      If you mean “how do I decide what goes in the template and what goes in a module?”: I prefer my templates be structural and (except for debugging) keep PERL blocks out of it entirely. If the code isn’t real simple, I find it’s more of a pain to write and maintain as part of the template than in a module. For example, when I have to generate a preview I generate it from the Markdown source. If you truncate Markdown source, you might end up separating the first and second parts of a reference link. That leaves Markdown bits in your rendered HTML, so you have to either clean that up or make sure you also grab the second part of any references. (Maybe instead I should render to HTML first and try to truncate that…) Either way that’s much more Perl than I want in a Template file.

      If you mean “how do I decide what’s model code and what’s view support code?”: I struggle with this distinction myself, and I’ve done it a few different ways. :D (I've actually thought about writing a question about this, but haven't gotten around to doing it.) One way I think about it is: if I had a command-line utility that needed the raw data for its own reasons, what would it want to call vs. what the web view wants to call?

      Mine are fairly small, single-person projects. I’m not part of a team. The stakes are small. I’m sure it's much different on larger team projects.

      – Aaron
      Preliminary operational tests were inconclusive. (The damn thing blew up.)
[reply]
        > I’m not quite sure what you’re asking, so I’ll answer it two different ways. :)

        This

        > MyApp::View namespace for that stuff to go in.

        Answers it already and reflects my "view" too. ;)

        I'd probably extend it in a way that the wrapper is initiated in the template.

        Like this it becomes a reusable feature and the designer can decide which texts need to be shortened.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

[reply]
[d/l]
        Mine are fairly small, single-person projects. I’m not part of a team. The stakes are small. I’m sure it's much different on larger team projects

        The project that prompted the question is a single-person project...

        Historically, my company has relied on Online Travel Agents (OTAs) - Airbnb, Booking.com, etc - for finding guests for our Furnished Holiday Lets. It was always part of the plan to have our own booking platform but it was on the list of things to do 'one day'. And then the Pesky Pandemic arrived and the OTAs basically cancelled all booking and wouldn't take new ones. Although people couldn't stay with us for leisure, there were plenty of valid reasons for people staying. So, suddenly the booking platform became very, very urgent.

        I created a fully functional booking platform from the ground up in a little over a week. On the backend there is a basic CMS to allow other team members to upload and change pictures and text.

        Last year when I created the booking platform, I knew of the Monastery but hadn't created an account and knew absolutely nothing about templating or separating logic from display or anything like that. So the whole system is very badly written but it does what it needed to do. Now, whilst I am quite proud of my achievement, I want to refactor the site to use Template along with use strict; and use *::*; instead of require */*.pl; and all sorts of other good practices that I have learnt in the Monastery. The reasons for refactoring are so that we can make incremental A-B testing changes much easier and so that someone else can take over the display and design at some time in the future; not to mention making maintenance easier!

        So, like you Radiola, this is a small, single person project in many ways. I am not part of a team although the stakes are probably a bit higher!
        Having the wisdom and support of the Monastery to call on makes the prospect of refactoring bearable - otherwise I would approach it as throwing away everything we have except the DB design and starting again from scratch...something that would forever remain on the 'one day' list.

[reply]
[d/l]
[select]
Re^2: Splitting long text for Template
by Bod (Parson) on Feb 08, 2021 at 17:45 UTC
    I have an app where the shortened “preview” can be supplied by the article author or editor

    The code in the question was significantly cut down to get to the core of the problem. In the actual implementation, there are two blocks of text. One is a preview and the other is the main text. It is the preview that we need to be able to toggle between just an extract and the full copy. Although even here I missed a bit out. The creator of the text can add a <split> tag to control where the block of text is split. In reality, this is not often used but it will remain in the refactored, templated code.

    Thanks for sharing - that gives me more food for thought.

[reply]

      Cool, that's very much the kind of thing I'm doing too. My logic goes:

      preview = pre-written preview || split-with-tag preview || generated preview

      The preview method (well, _build_preview — it's Moo) figures that all out so the Template only has to call one method and display what it's given.

      – Aaron
      Preliminary operational tests were inconclusive. (The damn thing blew up.)
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom