Cutesy dates (going full stack or not)

[sri]

The feature proposal in this branch may seem rather simple, but it represents a possible new chapter for Mojolicious.

    https://github.com/kraih/mojo/compare/time_in_words

We are not at the point where we are going to select a "blessed" model layer. But what we could do is shift away a bit from trying to provide only the absolute essentials, and start embracing more (and higher level) established best practices from outside the current Perl eco system, such as cutesy dates. What do you think, where should we draw the line when it comes to high level features?

--

sebastian

[sri]

Btw. i'm completely undecided on this, so any kind of feedback will have a lot of weight.

--

sebastian

[Gabriel Vieira]

IMHO it escapes the project focus.

Maybe a plugin would be better.

--
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 mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

--
Gabriel Vieira

[Scott Wiersdorf]

I don't know if there is such a line as long as there is a compelling need. A rule of thumb I (try to) follow with my own software is "would this delight people?" If Mojolicious had a tagline, it would be "Look how simple it is to do amazing things!" I think any feature that supports that is worth consideration.

With the cutesy dates specifically, however, we would probably want to make it I18N-able, which could open up a worm can, since (I think...) this would represent the first Mojo::* whose content isn't configurable (e.g. with a template). Is that right? Besides that small issue, I don't have a personal need for this kind of thing (I usually reach for Time::Piece these days), but others may have a stronger opinion.

[sri]

A few words about the motivation. Like many Perl hackers, since the closure of Google Groups i'm a regular visitor of the Planet Perl Iron Man site (http://ironman.enlightenedperl.org/), which is a very good example for something quickly hacked together and never cleaned up. You don't even have to look at the code, which still sports the stub documentation generated by Catalyst. One of the first thing that jumped into my eye were those horrible timestamps, even for a quick hack you should never have to choose those. Mojolicious needs to be better than that, making aesthetically pleasing applications has to be easy by default.

--

sebastian

[sri]

With the cutesy dates specifically, however, we would probably want to make it I18N-able, which could open up a worm can...

Indeed, I18N is currently still out of scope (for me), time_in_words is about providing an aesthetically pleasing default that plugins can redefine and extend with proper I18N support. It's about steering our users into the right direction.

--

sebastian 

[Stefan Adams]

I like it.

But I'm curious what the motivation is to bring it into core? I think we could all think of 1,000 things that our apps do and, starting from scratch, it would be convenient for these things to be built into core.

I would like to see more things that can help me out as a developer to make my application development easier, especially at the prototype stage. The more things the framework can do the less I have to do or glue in from other modules. :) And we all know that laziness is a virtue.

It's nice, I like it; but why isn't it a plugin? Seems to me like the logical choice for it?

In any case, I do very much like and appreciate your consideration of taking Mojolicious to the next level beyond the essentials and into the best practices. It seems to me that what you're proposing is to begin building a repository of plugins that are approved by the core team. The current plugins now: Android. The plugins that you're proposing: iOS. It might be nice to have a separate name space between the two so users immediately know which they're dealing with and also so that the good names don't get taken from the core team.

I've always been secretly hoping that one day Mojolicious would do more than essentials framework. I would love if it would do more and more things for me. It already does just about everything, why not let it do literally everything? :)

--

[sri]

...Google Groups...

Haha, it's of course Google Reader.

--

sebastian 

[Abhijit Menon-Sen]

At 2014-08-27 20:03:21 -0700, kra...@googlemail.com wrote:
>
> But what we could do is shift away a bit from trying to provide only
> the absolute essentials, and start embracing more (and higher level)
> established best practices from outside the current Perl eco system,
> such as cutesy dates.

I agree with the above in principle, but I'm not really a fan of the
proposed feature. I don't feel strongly about it at present, though.

-- ams

[Justin Hawkins]

On 28 Aug 2014, at 1:25 pm, sri <kra...@googlemail.com> wrote:

> A few words about the motivation. Like many Perl hackers, since the closure of Google Groups i'm a regular visitor of the Planet Perl Iron Man site (http://ironman.enlightenedperl.org/), which is a very good example for something quickly hacked together and never cleaned up. You don't even have to look at the code, which still sports the stub documentation generated by Catalyst. One of the first thing that jumped into my eye were those horrible timestamps, even for a quick hack you should never have to choose those. Mojolicious needs to be better than that, making aesthetically pleasing applications has to be easy by default.

I share this pet peeve. I’ve been using Time::Duration since … forever.

Mojo::Date has a nicer interface, but I still don’t know how I feel about it being in core.

I can see the arguments for - date and time handling comes up in almost any non-trivial web app, and you might as well make it look good and make sense.

Overall I think I’m in favour. Not sure about the ‘cutesy dates’ name :-)

- Justin

[Jan Henning Thorsen]

I also don't see this as a core feature. I would also not render relative timestamps on server side, but rather let this to be done on client side to improve caching. Something like this:

  <span data-timestamp="<%= time %>" class="timestamp><%= pretty_absolute_time %></span>

Doing it on the client side also has advantages by allowing the "less than a minute ago" string to be changed as time goes along in the browser.

[sri]

Looks like we have consensus in the community not to do this.

--

sebastian

[Stefan Adams]

On Thu, Aug 28, 2014 at 7:32 AM, Jan Henning Thorsen <jan.h...@thorsen.pm> wrote:

Something like this:

  <span data-timestamp="<%= time %>" class="timestamp><%= pretty_absolute_time %></span>

Are you saying that is on the client side?  But that's a Mojolicious template and therefore rendered on the server site, yes?  Isn't pretty_absolute_time a Perl function in this case?

[Jan Henning Thorsen]

Stefan: That is indeed a Mojolicious template. What I meant is that I want to provide a pretty absolute time (not like the ironman webpage) and then I replace that on the client side with whatever "data-timestamp" holds. time() = something computers (javascript) can understand and pretty_absolute_time() is something humans can read.

Another thing is that pretty_absolute_time() makes also more sense if you plan to print the webpage. Therefor I wouldn't replace the <span> tag, but rather hide it by default on "media screen" and show it on "media print".

[Stefan Adams]

On Thu, Aug 28, 2014 at 7:58 AM, Jan Henning Thorsen <jan.h...@thorsen.pm> wrote:

Stefan: That is indeed a Mojolicious template. What I meant is that I want to provide a pretty absolute time (not like the ironman webpage) and then I replace that on the client side with whatever "data-timestamp" holds. time() = something computers (javascript) can understand and pretty_absolute_time() is something humans can read.

Another thing is that pretty_absolute_time() makes also more sense if you plan to print the webpage. Therefor I wouldn't replace the <span> tag, but rather hide it by default on "media screen" and show it on "media print".

Thanks for the response, Jan.  I think this makes sense, however, as I understand it you're still calling a Perl function to output pretty time / cutesy dates -- the very function that Sri was proposing and that you were suggesting isn't useful because you like to render it on the client (javascript).  But it sounds like you are still rendering cutesy dates on the server.  I'm not suggesting that this is sufficient cause to introduce cutesy dates into Mojo core by any means, just trying to keep up with you in the conversation and understand your response and rationale.  Sorry for my inability to understand better.  :D

[Jan Henning Thorsen]

The big difference is that I got pretty ABSOLUTE time as a fallback, while https://github.com/kraih/mojo/compare/time_in_words is used to create pretty RELATIVE time.

[Stefan Adams]

On Aug 28, 2014 9:50 AM, "Jan Henning Thorsen" <jan.h...@thorsen.pm> wrote:
>
> The big difference is that I got pretty ABSOLUTE time as a fallback, while https://github.com/kraih/mojo/compare/time_in_words is used to create pretty RELATIVE time.

I understand the focus of your distinction now. "5:00 pm" versus "5 minutes ago". Yes?

Perhaps I missed it sri, I was curious what your motivation was for supplying relative time such as "5 minutes ago".

When I initially saw your commit I thought that you were interested in showing some core logging in the debugger that something happened 5 minutes ago or such.

Anyway... Sorry to beat a dead horse. Just curious.

> On Thursday, August 28, 2014 4:46:03 PM UTC+2, Stefan Adams wrote:
>>
>>
>> On Thu, Aug 28, 2014 at 7:58 AM, Jan Henning Thorsen <jan.h...@thorsen.pm> wrote:
>>>
>>> Stefan: That is indeed a Mojolicious template. What I meant is that I want to provide a pretty absolute time (not like the ironman webpage) and then I replace that on the client side with whatever "data-timestamp" holds. time() = something computers (javascript) can understand and pretty_absolute_time() is something humans can read.
>>>
>>> Another thing is that pretty_absolute_time() makes also more sense if you plan to print the webpage. Therefor I wouldn't replace the <span> tag, but rather hide it by default on "media screen" and show it on "media print".
>>
>>
>> Thanks for the response, Jan.  I think this makes sense, however, as I understand it you're still calling a Perl function to output pretty time / cutesy dates -- the very function that Sri was proposing and that you were suggesting isn't useful because you like to render it on the client (javascript).  But it sounds like you are still rendering cutesy dates on the server.  I'm not suggesting that this is sufficient cause to introduce cutesy dates into Mojo core by any means, just trying to keep up with you in the conversation and understand your response and rationale.  Sorry for my inability to understand better.  :D
>

[Jan Henning Thorsen]

Yes. "5:00 pm" versus "5 minutes ago" is a huge difference.

Yes. I think you missed the point. The point was to provide nice "timestamps" in templates (or where ever)

> To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscribe@googlegroups.com.

[sri]

Perhaps I missed it sri, I was curious what your motivation was for supplying relative time such as "5 minutes ago".

I don't think there is much value in dragging this discussion out, feedback from the community was clear, and i'm not going to pursue this kind of full stack ideas further.

--

sebastian

[Vytas]

Would you consider starting full CMS on top of Mojolicious ?

--
Vytas