Closed jails closed 6 years ago
Hey, good idea. Let 'er rip with the feedback, everyone!
I think the documentation has a long way to go as it needs MORE EXAMPLES, and certain sections have no documentation whatsoever.
Besides that, features that I would personally like to see added to the core are: A) A way to relate M-N models (i.e. A 'user' can have many 'posts', in other frameworks this is called a HABTM relationship). Anyone that's developing upon a relational db needs this. B) Migrations: it would be great to have db migrations tied to the core with 'up' and 'down' statements or something along those lines, to facilitate db maintenance.
@fduarte thanks for the suggestions!
I agree there should be more documentation. Maybe we can have a documentation hack day like symfony did a few weeks ago? I'd love to participate! Thoughts @jails @nateabele ?
1) Here is a wiki page with some examples with relationships.
2) There is a migration plugin here, I've not personally used it mostly because mongo is awesome. However I do think this would be a great core feature.
The doc needs a tutorial that goes a little more in depth into all the little things you can do with Lithium. Maybe incorporate the advent series you did on sphere into the doc?? Maybe make the lithify.me website a little clearer/more attractive for a newcomer? :)
Yo guys!
You know I love lithium but these are reasons we either can't use it in production at the BBC or the reasons why it is difficult.
I have chatted to Nate about these things so he knows I love you!
Just some ideas
Great initiative :)
composer create-project
commandlithium/framework
is imo a weird name, maybe lithium/app
or somethingcore
, data
, http?
whatnot, I should be able to build a CLI app using lithium components without having controllers and vice versa.I've chosen lithium as the framework for 2 in-production web applications, one DAM serving hundreds of thousands of media files and one sms application sending 500k messages a month, and I think at the current standing I would have to bring some good arguments to the table for my team to use it in another app. Things work, but I have a hard time bringing other developers properly into the knowledge fold of the framework, and when we hit a roadbump that bump turns out to be a rock that sends the developer crashing for too long.
A proper universal debugger that's stylish and useful ! we developed one for our main website but it's not quite ready for primetime, I might get around to open-sourcing it in the next weeks ! (works with static pages, ajax calls, and in console mode)
@mackstar I feel filters are testable now. Obviously they can be a pain in the rear if used incorrectly. At the day job we ended up making a directory app/filters
so each filter does have it's own class. There are two methods for each class enabled
and apply
. If enabled
is true, we call apply
. Now we can unit test them. Of course you can still have integration tests for filters that just test the behavior of the filtered method/class. Now most of my filters have a standard if(Foo::enabled()) { return Foo::apply($self, $params, $chain); }
maybe it's possible to get a new syntax:
Foo::applyFilter('bar', 'FooClass');
Foo::applyFilter('bar', 'FooClass::Bar', array('if' => 'FooClass::Enabled'));
@marcghorayeb what are some features of a debugger that you'd like to see? I love how we can currently click through the stack trace, but I suppose compared to pry or better errors it could use some work. Although I'm not sure how much is possible without a php extension.
@BlaineSch I like that implementation for filters, perhaps this could be added to framework bootstrap with a sample.
Honestly, I don't think I'm experienced enough as a PHP developer to pick out things about the framework itself. I think there are other non-code related issues that need to be address to help make 1.0 amazing.
Updated website to "sell" the framework. Think of lithium as a product, we need to tell people what the framework is and why they should use it. Showing quick code examples on the homepage would be key. Also, some attention to SEO would be useful.
As @nervetattoo mentioned, a "built with lithium" section would be useful. Also, links to featured tutorials and presentations would help ease in newcomers.
A more unified community While the idea behind sphere and lithium101 are nice, it all seems a bit disjointed from promoting the framework. Also an attempt was made at starting a forum, but it never caught on. I really enjoy having IRC as a resource, but it can be tough to get questions answered on there. Perhaps promoting posting to Stack Overflow directly from lithify.me.
Documentation Just reiterating what's been said, the docs need some help. They are amazing right now, but they are lacking some final polish. Also, I'm always unsure of which version the docs apply to. Easy answer is to either put the version tag directly on the docs, or a link to the latest branch.
Versions I know that we are rapidly iterating the framework, with new pull requests being merged to dev multiple times a day. Would it be possible to use a versioning pattern that was more indicative of these changes?
Activism In line with unifying the community, we need to get the word out there. Many of us love Lithium, but that message isn't catching on elsewhere. Having the backing of EngineYard is great, let's use that!
@BlaineSch I was more referring to a profiler that spits out the requests / exec time of db requests needed to display the page. My profiler currently handles different levels of details, db, cache, framework time, view render time. The current error page is sufficient I think.
Nice idea :-) First of all thanks for all your work!
i would like to see
Enough for know may be more to come later...
2 major things I wish LI3 was stronger at:
Concur with most of these sentiments:
$user->hasField('first_name');
My own frustrations:
conditions
all the time. The most common use case for an ORM in my experience is fetching instances based on multiple criteria; rarely can I take advantage of the __callStatic()
magic configurations... Which also need documentation.... it's not where it could be. Not a finger pointer, just sad this is the case right now.
A more listy approach:
also don't like the fact that li3 makes all the other frameworks look 'ugly', but that's probably a good thing ;)
P.S. I don't think open source means making other people doing the job, @jails @gwoo. If I could do the job, I would do it. It's just above my paygrade. But I do try to contribute to Lithium if I can, when I can, where I can...
I don't like not being able to keep up as fast as others do, but that is more about me than about the tool itself eheh. But i have to confess, sometimes it still looks like rocket science hehe. @Ciaro was on spot with some things such as the roadmap. I think if there was more info people would try to contribute more... You guys know lithium is top notch in the framework talk (let's keep it only with php from here) you talked about it so, the lack of orientation may be the major issue around the lack of contributions. It's not easy to master the best tool. Also, i miss the labs... It was such a great idea, plugging with composer, it could be the npm for lithium stuff. Oh, and the docs. Please guys, write down a roadmap, hack day or something, there would be a bunch of dudes (myself included) willing to help out where needed, no doubt in that. Oh, upgrading sphere, pastium and other stuff would be a good idea. They don't work properly so, they could use a hand or two. Rest of it, i bloody love lithium, its brand, its lemma and stuff and it's the only thing i use to rig php (that util stuff is handy everywhere, as others) and probably will be the last since php had seen better days so, keep up the awesome work fellaz.
First of all, great thoughts everyone, thanks for all your feedback so far.
@Ciaro:
session/cookies still has a lot of unresolved issues.
I agree there are still some outstanding issues with sessions and cookies that need to be resolved. Just so I have all the details (and maybe this should be a separate issue), what do you see as being the big issues, and how would you see that interface working?
@mackstar this is an attempt to make Lithium's model layer available to any project in any framework and / or flat php for that matter:
https://github.com/SayB/Li3Models
I guess now you can check that off your list :)
@SayB Thanks I am glad you are looking at this, but I am thinking about having a UOR driven 'Active Record' based library based on what we have learnt from #li3 models. There is a gaping hole in the PHP open source world for a decent library that is not Doctrine - which I am sure is why you created your library. Maybe you could help us in this?!
Cheers
@mackstar helping out in building such a library would definitely be exciting ... however, I wonder what else would need to be added ? - if not then it's just a matter of carving out the relevant classes and we're done, no ?
First I would just like to say, I've been using lithium for a while now and it's been such a boon to productivity. It is such a great balance between having an opinionated framework and something that is flexible enough to not get in your way. It is pretty amazing that whenever I run in to a problem that seems like it would clash with how lithium does things by default, I'm usually able to solve it with reconfiguring behavior via some class extending Adaptable. That being said here are two things I'd like to see.
Other than that, I could probably nitpick over other issues that would make the framework seem more legit or trendy, but really those are the two things that are holding lithium back in my opinion. When I first started following lithium, there was a great deal of excitement, especially after using CakePHP for some time. But like others have said before me, because 0.11 has been around for so long, I almost felt like the development had stopped and that the project was dead.
I know the framework very well at this point, so please let me know your vision for a 1.0 release and I will try to contribute as much as I can.
I'm using lithium in production at work and what we've found that lithium itself is very inefficient, in particular with the models/ORM. Retrieving > 6 records means rewriting to directly connect to the database. At the same time, we see the memory spike on each request so it's slow and memory-intensive.
The other problem is that we still haven't found a really good way to debug lithium problems because of the use of filters. Has anybody found a good way to debug the filters? XDebug died when one of our other devs used it.
Besides that the other problems have been mentioned already: better/more documentation and tutorials, composer integration
@ThomasWunderlich I debug Lithium using XDebug on a Windows box and never have any issues. Currently, I'm using PHP 5.4.11 and XDebug 2.2.1. Perhaps your xdebug.max_nesting_level
is set too low?
@ericcholis The other dev said he hit 175 levels, so I'm not sure what he was debugging. I would hope that he wouldn't have to increase the levels above that. Obviously something caused it to go recursive but I didn't ask what. But thanks.
Weird, I've always seen Lithium perform very well with profiling. Part of why I love Lithium is because of its high performance. I'd be careful with how many filters you use. They are a wonderful feature with Lithium, but they must be used appropriately. Yes - debugging them is difficult and it may also be the source of some of your performance issues (and recursive issues) depending on what you're doing.
@ThomasWunderlich, thanks for reporting, however it would be really interesting to see the code behind these performance issues, otherwise we can't do much to improve things.
I often recommend Lithium to my coworkers. Firstly all of them are impressed, but shortly after they recognize the lack of manual and particularly the incompleteness of mongo relations they just turn away.
The latter one would be wonderful as a Christmas Gift!
@kszucs
The funny part mongo relations
, but I completely understand. You can still have mongo relations I believe there are a few plugins our team has developed/used.
The li3_fake_model does a bit more specific to our needs like not creating excessive objects for nested items in your mongo object, and does great with relationship querying for performance boosts.
@nervetattoo, @ericcholis There is now an "in the wild"/built with li3 section in the wiki at https://github.com/UnionOfRAD/lithium/wiki/In-The-Wild. @ericcholis There's now a page with all presentations and talks I've found so far at https://github.com/UnionOfRAD/lithium/wiki/Presentations%2C-Press%2C-Audio-and-Video.
I hope that at some point we can just interface with the github wiki and pull/parse data from those pages in order to integrate it in the li3 website. That however is just an idea and would work only if those pages are kept structured.
Sucks that the old domains have been lost (i.e. - lithify.me now goes to Lithium SEO), yet Google still associates lithify.me with Lithium framework.
The website still is in sore need of love.
Clicking on forum
(aka sphere) takes you to https://blog.engineyard.com/
as the intended URL no longer exists.
Support > bin still links to Pastium which is pretty much dead, switch to Gist already.
But really the biggest flaws with Li3 have already been covered. Website is lacking when you compare to the likes of Yii, Symfony, Laravel, etc. Still not at v1.0 final (which is a shame, as this framework was launched around launch of 5.3, yet now PHP 5.5 is out, with 5.6 on the way). And community doesn't feel immediately accessible (meaning, easy to find).
Ugh...and lithium so isn't considered an issue by lithium technologies?? Guess we'll see. What a crock of poo poo. The whole domain thing is a great example of what's wrong with our entire industry and why it's such bs. Stuff like that makes me want to change careers to one where there aren't little kids with severe mental health issues running things.
Anyway, (rant aside) I agree about lack of guides, etc. Though I wouldn't worry so much about a "stable" tag. I mean we can put one on there really... but look at frameworks like Laravel for example. That is a wonderful example of why you don't slap "stable" on things for fun. The framework is on a 6 month release cycle (by its own choice), suffers from horrendous breaking changes and it's API is caught in the balance between core Laravel architecture decisions and Symfony2 API changes. This gets in the way ALL the time. It's one of the most unstable frameworks I've seen to be honest.
My thought, Li3 is so superior that most folks are too afraid to jump in. It's like a form of atychiphobia where the fear to use and contribute is unwarrented and unfortunate. I believe a bit of love to the Li3 website, setup guide, docs could address this fear. At the moment, folks (more-so beginner PHP devs) have to dig deep to find out why they should even pick it up. Its awesomeness is hidden. There, I said it!
I wish to re-iterate the sentiments mostly stated above:
Nice to see some life here in this thread. Let's get this project to 1.0, expand the docs, and redesign/reorganize the website. So then we can feel satisfied we completed this project and can all move on recreating it on node.js ;)
I've been using a version of lithium in production from somewhere around the 0.10 release with a few custom bug fixes for many apps over the last few years. I've been sort of waiting for that 1.0 tag to go about migrating... and just lazy. If it ain't broke...
I could see the use of traits helping with everything needing to extend from StaticObject
and Object
to add filter and dependency injection support. Making something Adaptable
could also be a trait.
I've been using a trait to turn models into mocks by replacing a few methods and using a mock database connection. I think initially the reaction to traits was that we had a hard time getting people to 5.3, we shouldn't now require 5.4. I thought maybe people would be upgrading the minor php release numbers a little more regularly now. But w3techs shows 5.3 still has a lot more usage compared to 5.4 and 5.5. I mean... who doesn't want to upgrade to 5.5 just to not have to write array()
anymore?
I've been silently working on a redesigned and restructured website and hopefully have something to look at in the upcoming 2 months :)
Not so secret now eh? ;-)
On Wed, May 21, 2014 at 11:23 AM, David Persson notifications@github.comwrote:
I've been silently working on a redesigned and restructured website and hopefully have something to look at in the upcoming 2 months :)
— Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/issues/887#issuecomment-43769691 .
Er, silent rather. Damnit fast response!
On Wed, May 21, 2014 at 11:23 AM, Jonathan Langevin jon@langevin.me wrote:
Not so secret now eh? ;-)
On Wed, May 21, 2014 at 11:23 AM, David Persson notifications@github.comwrote:
I've been silently working on a redesigned and restructured website and hopefully have something to look at in the upcoming 2 months :)
— Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/issues/887#issuecomment-43769691 .
@davidpersson let me know if you need an extra hand. Would love to help. I just lack the commitment to do it alone.
@rapzo thanks for offering a helping hand :) I don't yet have a fix roadmap for the new site, thus I don't want to promise too much up front.
I'll be creating a repository containing my current local changes (these will form the basis for the new site) once I'm not busy with other stuff anymore.
Once I'm this far I'll determine what needs to be done. We can coordinate via the li3-core channel. Then get our hands dirty. I'll notify you once there's a repository available for everyone to see.
Aye cool! Count me in.
On Thu, May 29, 2014 at 1:22 PM, David Persson notifications@github.com wrote:
@rapzo https://github.com/rapzo thanks for offering a helping hand :) I don't yet have a fix roadmap for the new site, thus I don't want to promise too much up front. I'll be creating a repository containing my current local changes (these will form the basis for the new site). Once I'm this far I'll determine what needs to be done. We can coordinate via the li3-core channel. Then get our hands dirty. I'll notify you once there's a repository available for everyone to see.
— Reply to this email directly or view it on GitHub https://github.com/UnionOfRAD/lithium/issues/887#issuecomment-44525944.
Rui Pedro Lima
@davidpersson me, too.
aight :)
I'm considering lithium for a project but after taking it on a test drive yesterday, I'm not really convinced. The promises and approach seems really good and I want to like it, but:
Mongo
and MongoClient
. Sure, it's easy to fix, but still.String
and Text
I think)The things that work are elegant and work well, but overall and from the outset I'm not sure li3 is production grade yet.
@y-lohse it's definitely not. Afaik, it's never hit a final stable release (as you noted, 1.0 is still beta). Additionally, I think it's important to have a thriving community around a project, to warrant it's usage, because then there's less chance it becomes abandonware. lithium has a small dedicated community, but pretty much only in IRC or similar. It's a real shame, as when lithium first hit the scene, it was extremely promising. Since then, Symfony 2 has iterated multiple times, and now with Laravel available & a large community surrounding it, I don't see how lithium can be justified right now, except to do something different, but not for everyday use.
Thanks for the clear answer! I agree, what a shame :(. The search goes on.
@y-lohse @intel352 I wouldn't say Lithium isn't "stable" - it just hasn't yet labeled itself as that "1.0" we all cling to (please do keep in mind that nothing is "stable" on the web). The Lithium team is very careful about these things (there's a roadmap somewhere) to avoid "maintenance hell."
Lithium is most certainly production grade and has been used in production for many years for many projects with very good results. I assure you, it is extremely capable.
In fact, I do agree with your findings @y-lohse and they are items of discussion and are in the process of being addressed. I would suggest trying the dev
branch in the meantime (not 1.1 - unless something has changed and my understanding is dated).
Composer does indeed work with Lithium. Though I'm not a fan of it because it's slooooooooowwwwwww as all heck, but fortunately Lithium doesn't use its autoloader. So I can live with it for dependency management (which is also fairly slow, but recently got faster).
If you are looking for something a little more opinionated, I could definitely see where Lithium isn't cutting it. You'll likely need to make your own set of boilerplate code that you can use for your projects that's a bit more opinionated (I use https://github.com/tmaiaroto/blackprint - fair warning, work in progress, but might give you some ideas).
Definitely good to hear more feedback!
I agree with @tmaiaroto on this one, I've been using the dev branch in production for almost a year now, and the master branch for two years before that. Both branches on a site that gets 1.5 million+ pageviews per month.
Actually, very rarely have I come across instabilities that were entirely the fault of li3. Also, in the event of a bug, the project maintainers and community have fixed it rather quickly. I recommend looking through the issues and commit history to see what I'm talking about.
Lithium feels more like a solid foundation for your own project, rather than a large toolbox like Symfony. WIth that being said, Composer allows amazing flexibility to include many things that might not be included. Hell, you could even skip the built in ORM and use something like Doctrine or Propel if you felt that Lithium's wasn't cutting it.
As for the small community, it can't get larger on it's own. People need to use and contribute in order for it to grow. It seems that Laravel landed at the right time and was picked up by the community rather quickly.
Guys ... this has not helped me to sell the idea to my employers at all! ... I've got the same answer twice: "It's not production ready yet". The only way I can see me using Li3 now is for my own projects.
On Wed, Jul 1, 2015 at 10:15 AM, Eric Cholis notifications@github.com wrote:
I agree with @tmaiaroto https://github.com/tmaiaroto on this one, I've been using the dev branch in production for almost a year now, and the master branch for two years before that. Both branches on a site that gets 1.5 million+ pageviews per month.
Actually, very rarely have I come across instabilities that were entirely the fault of li3. Also, in the event of a bug, the project maintainers and small community have fixed it rather quickly. I recommend looking through the issues and commit history to see what I'm talking about.
Lithium feels more like a solid foundation for your own project, rather than a large toolbox like Symfony. WIth that being said, Composer allows amazing flexibility to include many things that might not be included. Hell, you could even skip the built in ORM and use something like Doctrine or Propel if you felt that Lithium's wasn't cutting it.
— Reply to this email directly or view it on GitHub https://github.com/UnionOfRAD/lithium/issues/887#issuecomment-117690821.
Regards, Sohaib Muneer Voice: 647-983-5903 http://blog.sohaibmuneer.com
edit: Realized that my comments might have been a bit standoffish
Sorry @SayB, perhaps some production metrics would be helpful. To reiterate:
I've been using the dev branch in production for almost a year now, and the master branch for two years before that. Both branches on a site that gets 1.5 million+ pageviews per month.
Production ready, in my opinion, is defined by the needs of the organization. In my case, when I started my project, I needed a strong PHP 5.4+ framework with baked-in support for MongoDB. What I got was a solid foundation that has been easily extensible. My needs have since shifted, but have always been met given the nature of the PHP community. Composer and it's packages filled any gaps that Lithium may have had.
As for stability and performance:
Last 3 months | July 2014 to June 2015 | |
---|---|---|
Response Time | 295 ms | 276 ms |
Uptime | 100% | 99.87% |
Requests (millions) | 6.8 | 8.1 |
Downtime has been attributed to bad user-code, network issues, or 3rd party service issues. With the advent of PHP 7, I'm hoping to see average response times below 200 ms.
You should, of course, use this information anecdotally and compare the available frameworks to decide what is best for the needs of your project and organization.
@intel352, in nowaday's developement, I'm not sure there's still some "bug free" libraries around. So flagging a library as "stable release" doesn't make it more stable. If you are looking at Symfony issues or even Laravel, the li3 ones are for most of them enhancements and not bugs related.
Personnaly I'm not choosing a library according to the community around. If the code base of a library doesn't make a lot of sense, no matter the community is, I'll do my best to avoid using it. Sooner or later you will need to dig into the code base of the libraries you are using to deal with some core bugs. Moreover, if the library contains some bad architecture choices it will leads you right up the wall. So you can easily waste all your profits to deal with some "unsortable" mess. I know the community size reassures people. Indeed nobody want to be alone when something bad happen. But how something bad can happen if you are understanding the libraries you are using ? I know it's quite an investment, but wasting your time posting issues and beg for help is quite time consuming too and won't make you a better coder.
@y-lohse However it'll mostly depends on your need. If you need a lot of well defined features and are somehow compliant and not well experimented. Using a framework with a big community behind will help you to be productive in no time. But if you want to go rogue, you will waste the time you gained in the first part to finally get a messy application.
Personnaly I'm using li3 as a kind of toolbox and using some dedicated libraries for doing a job instead of following the "framework way" and get stuck as soon as I'm facing a custom use case. And nowaday with Angular, React and all other front end tools around, li3 could be splitted up even further.
@SayB Ask them why.
I've been in your shoes before and I completely understand and sympathize with you. There comes a time in every programmer's life where the training wheels come off and they realize that version numbers are not an indication of "stable" or "production ready" but rather numeric devices intended to signify changes and what you're working with. That web and software and computers aren't as reliable as we'd like to believe. Unfortunately this time never comes for "employers."
Don't be shy, express yourself on things you don't like in Li3. Don't be stingy with criticisms (I personally like being abused). Makes your criticism as detailed as possible with comparisons with how it works with your favorite framework if possible.
Thanks in advance for helping us to make Li3 an even better framework.