Long time perl-against-dbd-pg guy. It is my humble opinion that mojolicious could be a big help in bringing more coders back to perl, or to take the plunge with perl.
Mojolicious should make sense to nodejs programmers in particular, and I think this project would be a nice entry for many.
Personally, it was a framework on top of a framework that served as the terrain for my long relationship with perl. The Bricolage framework was written against HTML::Mason, mod_perl and DBI, and gave me a lot of structure and solid practices to copy. Cheers to David Wheeler for that.
If this project is done with the same quality it could help many people grasp and use mojolicious quickly and (hopefully) thoughtfully.
To elaborate a bit.
Ado ensures high quality by using Test::Perl::Critic in development mode as optional dependency. This way we will impose a uniform coding style and will avoid bugs. This was mentioned in the project description already.
Here is how I propose to do that: (https://github.com/kberov/Ado/wiki/Devnotes). This is how I do it at least. This applies for all sub-tasks(e.g. Ado::Plugin::Admin, Ado::Plugin::Site etc.).
For sure I am open for feedback and advices from gurus. It is impossible for someone alone to do it all and with high quality. At least some discussion must take place. And this is the way for anybody wishing to influence the project. Till now I tried to read, understand and apply what I already was seeing in Mojolicious.
Please, in the respective projects' repositories in Github (to be created), use the "Issues" form to express your wishes and constructive criticism.
Still for the sake of making this project happen on time and within the budged, let's restraint our self to the deliverables described above, i.e. no additional features please, unless they happen to prove as being "must-have".
As a web developer and perl lover for so many years, I'm glad to see Ado here.
I have written so much pseudo frameworks (framework is a big word here) on my own, depending on what each project needs. I've used mod_perl and catalyst so many times. Lately I'm using Mojo.
I really grew tired of starting all over again for each new project. Surely I've reused some old code, but I was dreaming for the moment when I will be able to write my own framework which will give me the following:
1. Fast and easy deployment with basic functionality informational site (kinda static site)
2. Integrated user management.
3. Integrated Admin Panel.
4. Easy way to extend the project with extra functionality (eg. gallery, forum, etc.). I was thinking of modules made as plugins (what else...). Every plugin should introduce it's stuff into the admin panel too.
5. Write many plugins.
Basically something similar to most PHP CMS systems, but written in Perl, hence better than every PHP CMS.
Then... at some point in the time, I've found Ado.
I was so happy while reading it's documentation... I was thinking: finally, someone did it, I can just join this project, instead of writing it from scratch.
I really like that Ado is based on Mojo, or more like it extends Mojo in it's own way.
Thanks to Mr.Berov, we now have a good base for CMS based on Mojo (which is the best option IMO).
I've joined the project some time ago, but still have to commit my ideas.
I'm really exited with Ado.
Give it a try and you'll like it too. ;)
I second Mike's and Stanislav's comments.
Can't comment on the code quality of what is already available as Ado on CPAN, but otherwise
- this proposal is quite detailed => apparently the author was willing to invest some time
- it seems to not re-invent something that's already there (there's the Galileo CMS - https://metacpan.org/pod/Galileo - but Ado seems to aim higher)
- it sounds like the outcome could provide real benefit
- deliverables include docs / tutorials.
- break it down to 3 or 4 parts, with partial payments due after the completion of each part.
- add requirement of a "product"/"project" website (running on Ado, of course) to enhance visibility outside CPAN echo chamber
Only caveat: would be nice if some perl people working in this area could provide their insight, if the things proposed above make sense and if it could be beneficial for them in their professional work.
Without any comment on any other aspect of the proposal, I wanted to define exactly what will be delivered to the CPAN.
Currently ado is lgpl-v3. If the Perl foundation did sponsor this would the code be released under the artistic license? Does Krasimer have all the copyright to the existing code in order to offer it under an artistic license?
I am concerned about the listed "benefits to the Perl community" in the proposal. Many of them don't really read as benefits, or at least don't seem like benefits that are unique to Ado.
The premise seems to be that a CMS running on Mojolicious is a good idea. I tend to agree with this. I'd love to see a real competitor to Wordpress emerge in Perl.
But is this the right CMS to back? Will it get the popularity that Wordpress has? Is this the best use of $4,500? Perhaps the answer is yes, but I haven't seen enough information to make that conclusion.
The only thing I see that gives the project any credibility at all is a long standing commit history with multiple contributors: https://github.com/kberov/Ado/graphs/contributors
I would have liked to see the code at least have a project website (maybe running on Ado) with a few links to real sites where it is in use right now. Perhaps testimonies from other devs that are using Ado. Really anything to give Ado more credibility would be persuasive. Before investing the community's contributions, I'd like to see some more assurance that the project we are investing in will have a real future.
There haven´t been many "cool" new projects written in Perl in recent years that gained widespread popularity and established a community. Enthusiastic young programmers seem to lean to other programming languages nowadays.
If Ado could or will "get the popularity that Wordpress has" is unpredictable. If it will even survive for considerable time is equally unknown.
To me, granting this request would/could/should be seen as an investment both in supporting the existing perl community by extending their toolkit and in providing a means for marketing perl to people outside the existing community.
That´s why I also suggested making a project website (running on Ado) a requirement (cf. previous comment).
In comparison to low level libraries and frameworks this has at least a bit more potential for establishing a community and being used to "show off" or brag about.
I share your concerns that having a stronger basis for deciding on this grant request would be good but I´m not sure how that could be achieved.
Maybe the decision on the granting of this request could be postponed until after such a website has been established and showcases some real world use of Ado?
Or maybe the request could be granted but the grant period would start only after the website was published?
@hjansen, Thank you!
Yes, there are already many frameworks, and yes it'd be good to see it running publicly, and yes, etc.
Even so, Mojo is a sophisticated basis for such work, and my preference, and the thoroughness of the work done, and discussed above, suggests that I (at least) can be optimistic of great success in the task of attaining the project's goals.
So - I'd like to see this project get funding.
Sigh - In the old days I could log in here to comment, but no longer. Oh, well.
It's catch 22; The grant would not be needed if there were multiple sites running Ado already.
This came up from discussion within the Grants Committee.
As some people mentioned, there are a number of web frameworks already. What problems specifically is Ado (trying|going) to solve? What makes Ado unique?
Here they are:
Not so much of a framework, rather a ready to use application to quickly bootstrap customizable projects. Think "A Site with Control Panel, users management pages management, blog in 5 minutes!" This will bring immediate income to one-man shops.
Reduce the time needed to have something (working!) to show to the customer from one week to one day. (Reduced time to market) Ado(.pm) +Ado::Plugin is the needed tiny layer for such an application. Task::Ado::Site aims to be much like Django CMS https://www.django-cms.org/ - "easy-to-use and developer-friendly CMS".
I like this project and want to see it get funded. Why? It's cool, it's light and it pretends to give us something more than "Just an another CMS framework from very short list of Perl CMSs".
I know the author and he's real professional, so the final product is guaranteed!
Again, when I say "much like" I mean only "easy-to-use and developer-friendly CMS in Perl" - nothing else.
Here is a UI draft (I made yesterday) of the administration panel dashboard https://github.com/kberov/Ado-Plugin-Admin/issues/4
Put it otherwise - a tiny application on top of Mojolicious for managing customizable web-sites.
Look and feel of the UI will be what I found most intuitive during the years. Of course everybody is encouraged to influence the details of the implementation.
I share the concerns Makoto Nozaki mentioned. I'm not sure the benefit for the perl community is really all that big. The world has plenty of CMSish systems (including some in Perl), just because one more in Perl exists doesn't mean people will switch to using it.
(problems that Ado is trying to solve)
1. We will attract those who are biased - growth in Perl expertise and retainment of community members.
2. Anybody generally preferring Perl would use it if it does not give him/her more hurdle than a PHP alternative - retain existing community members.
3. Any web-programmer wanting to try Perl would look for a web app that can be installed easily - new joiners.
1. Fresh code leveraging fresh framework. Lack of "historical reasons". Concentrating on application logic leaving the underlying framework to do the tedious job. Separation of concerns.
2. Imposed uniform coding style and best practices. Following paradigms from a popular framework - Mojo. Who knows Mojo can pick up quickly Ado and vice-versa.
3. User and developer friendliness. Reasonable simplicity. Light on dependencies - not requiring half of the CPAN. Ease of code management. advanced usage of Module::Build.