• Content count

  • Joined

  • Last visited

  1. Why create your own Framework?

    Symfony could've been a good base, like it is for Drupal 8. Flow could've been a choice, or even Laravel (but the really awesome versions of Laravel weren't ready when development of IPS 4.0 began, so... ;))And why I don't use IPS 4? Because it still only supports MySQL (whereas other frameworks allow about any database, as long as there is a driver for it) and I don't use MySQL in any way anymore. (In fact I wouldn't touch it with pincers if I can avoid it *g*)Anyway, I'm repeating myself over and over again. I've literally answered the same questions multiple times now.I was here to state my personal opinion as a full-time developer and a hobby-web-developer as on what holds me back to further support IPS-Software.Then I was here to stand against misinformation such as "Security by Obscurity is good" (which it is not and will never be! The safety of a system must be based upon mathematics not upon keeping an algorithm safe) and simple misunderstandings such as comparing another commercial "closed source" product like an editor with an open source framework and the problems that arise with the former.So, have a wonderful day, enjoy this product and have fun with the future of it (I hope it will be bright)!
  2. Why create your own Framework?

    "Unified user experience" For the greatest part this comes down to usability and ui-design and has little to do with the implementation of the functionality itself. If you structured your application well the package shouldn't add anything to this, except for the functionality itself. The integration part should be solved by Interfaces (as in PHP Interface) so that you could exchange one package with the other easily, without even realizing it happened. Personally I'm all for decoupling as much as possible so it can be reused :)
  3. Why create your own Framework?

    Well, for those there are not-self-hosted services and there you could run updates again ;)
  4. Why create your own Framework?

    Depends on the shared hosting, I'd say. I used to have shared hosting, but had ssh-access. If you don't have access to composer, you may still install and update your application via ftp, it's just more work :/ (unless the packages are packed with all dependencies with a cron-job or so :))
  5. Why create your own Framework?

    Ya, but if you build a boat you see what all ships have in common, some kind of hulk and that's where I'd use a lightweight (or heavy) hulk that suits my needs best, unless I wanted to do something that has never been done before, but then it wouldn't be a boat, now would it? :D Yes, absolutely, the modifications authors are great! That's what I love about composer nowadays. Everyone who creates a package can share it with the entire php-community! And that's where my critics hit in: When I develop for IPS the thing I made is bound to IPS... I can't give it to other non IPB-users without having to rewrite a whole lot of code. And as I do all of this for free I simply decide to do it for the majority in the first place. For you that's not bad, because that way the developers are more bounded to you, but for me it's a waste of time. Not because your framework isn't any good, but because it's bound to you alone. Ah, monkey patching is absolutely possible with other frameworks (example: Laravel 4 or greater). The IoC-Container is the way to go there. See, great minds think alike, so you invented the same thing as was invented already, maybe at the same time, but L4 is released since 14 months or so. But the real problem is, that a company such as yours simply can't fulfill even all basic needs, because you have so much to tackle down. Let me give you a concrete example: You don't have any interest to support other databases like Postgres or MongoDB etc. From a business point of view I totally understand this. Most hosts out there only provide MySQL in shared hosting and the absolute majority of your customers is quite content with this or does not care at all. However, supporting other databases wouldn't be a problem if used a portion of another framework for this. For example, I've written 3 packages that need a database connection to work and the abstraction layer provided by the framework I use make it really easy for me to test this stuff. They work on any database that has a driver in the framework (e.g. sqlite, postgresql, mysql, mongodb ...) so anyone can use them. The other packages I made framework-agnostic, so when you use the framework I do, you just add two lines to your config and off you go, but if you use another framework that's absolutely fine too. I would really love with IPS again and put time into this, so hopefully you'll go the composer way some time in the future and add support for alternate databases. :smile: Anyway, thanks a lot for taking your time to answer.
  6. Why create your own Framework?

    I was not trying to teach them their jobs, I was pointing out and reviving a discussion why I (and probably other developers too) can't afford to put time into it and stating my point of view regarding this topic. (And dealing with nonsense like "Security by obscurity is good" ... yes, absolutely, because it contradicts Kerckhoffs's principle *g* *scnr*) I didn't wait to raise my opinion, because I know now, that as it stands I can't put time into yet another framework that is unique to this software. It's the same reason I don't put time into any other "proprietary" solution... my time is not endless and in IT I hate nothing more than binding myself to a non open software. I'm putting so much of my free time into free open source software and I had loved if I could've incorporated IPS-customers into this. While I do create software to make a living, I never sold a package, because I gave them away for free.
  7. Why create your own Framework?

    Ahem, old topic, but that's the core of the problem here: The difference is: this editor was NOT free (as in money), neither was it open source! I can't fix my car, if I'm not a mechanic or the car is welded so I can't open the cowl. But I may be able to fix my Kernel, if I use an open source operating system and know quite a bit about C-Programming. The essence of an open source product is, that anyone can add changes. And even if the majority of people says "Nah, this is bullfaeces", the one who edited this, can still use it. If it is good it gets added and many can profit, if not, you can still use the work of others but have to maintain the things others don't want or you don't want to share.
  8. Why create your own Framework?

    I did not say you don't have one, I said using an existing one would have saved you time and enabled us customers to use IPS software without being bound to MySQL alone, which isn't always a possible option. (Take Symfony2's Doctrine or Laravels Eloquent for example ;) Both run a multitude of Databases out of the box!) For example: I wouldn't use MySQL for my personal or work projects any time soon, because I've moved my attention to Postgres and MongoDB.
  9. Why create your own Framework?

    Another thing, for example: The whole database-abstraction layer could've been used from another framework. That way customers of IPB wouldn't be bound to MySQL but be able to use other relational DBMS and even some NoSQL-databases without much of a hassle. Creating these kinds of things over and over again doesn't proof anything, it doesn't get better or more tested (I think that for a rather small company quite the opposite is the case - at least that's my experience when working for smaller companies, they simply can't afford as much [unit]testing as bigger ones or the open source scene), nor does it get easier or anything, it's just appears to be the good old "Not invented here"-syndrome :sad: Well, personally I still hope that one day IPS will jump on the composer (or whatever is the old bull then) wagon, no matter their framework. :smile:
  10. Why create your own Framework?

    So, first of all, let me clarify a few things: I wasn't suggesting to use a closed source framework of any other company, I was merely suggesting building upon a well maintained base that is developed by hundreds or even thousands of developers around the globe and is completely open source and free to use in commercial products. These frameworks are not only used by much bigger companies than IPS and maintained by a far bigger team than IPS has, but they are highly extensible, so forking and changing the core wouldn't be necessary in like 99% of all more or less possible cases. Still, if against the odds there really would arise a problem where IPS would have to create a workaround, "hacking" the core they could simply fork the project and provide a patch for the entire php community to use (if they wanted to). Creating your own code is absolutely okay, if it has more benefits. The thing is that, at least for me, my time is limited and I simply can't afford to learn 20 different frameworks for 20 different software products. It's just not gonna happen. Although I know the language and I know the concepts, really diving into a framework does take time. Hence I would've loved if people using IPS-Software could've shared their products with the rest of us and vice versa. Like it is now, IPS is not composer-ready, so IPS is like an entire other world, while the rest of the PHP-world that uses composer can share their projects and save a lot of time and efforts. While IPS could create their own framework, just look how long it took them to create it. They essentially had to create all the basics as well, instead of just being able to build upon a well maintained foundation and focus on the actual features and usability. Exactly. There is general misconception here. People assume that they would bind themselves to another company and be a at its mercy, which is absolutely not the case with open source software.
  11. Why create your own Framework?

    If windows was written of top of Linux it would inherit a far superior architecture (yes, beat me to it, but the architecture of the "near to unix like-" linux _IS_ superior to Windows) and there is no reason they couldn't do this. You know "free software" doesn't mean it has to be free of charge, just that the source code is open source and you're free to do (basically) anything you want with the code. I'd still say that everyone making his own cup of tea (or framework in that case) is a waste of resources :smile:
  12. Why create your own Framework?

    In Laravel: http://four.laravel.com/docs/ioc Other frameworks have other methods to achieve that. It's really nothing special anymore. Regarding the rest of the answers: First of, Charles. Yes, I still intend to leave, but I was asked some questions and wanted to be polite. For the rest: The development of these frameworks and composer is by far faster than anything that IPS has developed in the last couple of years. You chose another way, I asked why, I got my answers, tried to discuss this but you still seem to have your reasons and I'm fine with that. It's not like I'm crying because of your decision, it's just that I won't be able to use IPS-Software then because I wannt to put my work into the whole PHP-Community and not just one commercial software. I'm glad you all (even those who have no idea of programming) had a great laugh and a new concept of an enemy for a few hours. @Marcher: I'm sorry, this really is my last answer to you. The decision has been made, I see the reasons for it, can't with them and that's why I'll leave again. Enjoy your products and may IPS not fail to produce what you're searching for.
  13. Why create your own Framework?

    That's why packages try to be as small as possible. But yes, you're loading all the stuff that belongs to that package. If that is wasteful to you, that may well be your opinion. I'd rather "waste" some disk-space than my time in reinventing half of an application of thrice the size of IP.Board ;) Which can be dozens of hours someone has to pay for. This was my very last post here, I don't feel the need to discuss in a tone like that.
  14. Why create your own Framework?

    It would depend on how the guy programmed his app, wouldn't it? I mean if he just made it to be spaghetticode in one file I'd sure have to edit his code to add functionality, but this depends on the app itself. Have a look at: https://packagist.org/ All these, and more, are available out of the box to your composer-projects. You just add a few lines to a composer.json-file and composer does the rest for you. The Hooks I know from IP-Products are great but certainly not unique. Just have a look at modern frameworks. I never had to change the code I used from packagist, but I did extend it (without any hassle) Why would I spend my precious time to work with an application backed by one company if I can work with composer that intertwines with major frameworks such as Laravel, YII or Symfony 2. Hell even CI had hooks years back. edit: It seems like some of you feel attacked by my opinion. Well, this wasn't my intention and I'm sorry. It's just that once I really liked IPB and I got a little excited when the newsletter reached me. But now I simply don't wanna support twenty frameworks anymore. These times have passed (luckily) so IPS-Products are not an alternative anymore, currently. I just love to be able to share my code without the need to adapt it to five different frameworks and others are glad as well, because they spend less time porting applications that were made for Framework A to Framework B. It's also great to be able to use the efforts others have already taken without much of a hassle. To me it's just a waste of time to develop the same stuff over and over again for different frameworks. I wouldn't mind if IPS would use their own framework if it was composer-ready and thus easily extendable by all applications. But I guess this could lead to more support-requests on your side and less control of the people. Now you need to use a bridge to integrate differend software with IP.B. Then you could simply add IP.Board to, let's say, Drupal 8. So basically people who's needs are fulfilled with D8 and IP.Board wouldn't think about buying IP.Content and all the other products. In my eyes composer is the bright future of PHP. Something Ruby (on Rails) has since eons. This development brought me back to this language. Anyways, so this was it from my side. Have a nice day, enjoy your products and farewell.