Nowadays OOP is a must in any application if you want to keep pace with
technology. Using tools such as composer and npm would also help.
Yep time is an important factor. You never know when another person/company
use your idea with better technology and provide a better service than you
are doing.
And btw Yusuf, why the need for a micro-framework? Isn't that like
reinventing the wheel unless you have any new idea to implement which
current frameworks doesn't have?
Regards
Yuv
On Sat, May 9, 2015 at 2:30 PM, fluxy <fx_at_fluxy.net> wrote:
> Hello,
> I have checked the code around a bit.
> I have gone through the code and I very much share Yuv's concerns.
>
> PHP-FIG is a definite must, because different people/teams have different
> conventions, but FIG gives us a standard to make collaboration easier:
> - on the code level itself
> - on sharing / integrating 3rd party modules (using composer)
>
> Of the things I have noticed in my preliminary assessment,
>
> *- Better use of namespace (again FIG):*
> 1st level of namespace for vendor: Parixiscms
> 2nd level of namespace for logical object grouping: Controllers
> 3rd level of namespace for object (more subnamespaces possible but 3 is a
> good minimum): Frontend
>
> giving us Parixiscms\Controllers\Frontend
>
> Now tomorrow I may want to import and use your framework - I might want to
> extend certain elements with respect to specific application logic, whilst
> your cms itself should remain generic and re-usable, while allowing me to
> extend it without modifying the core elements, so I can have
> Myapp\Controllers\Frontend which extends Parixiscms\Controllers\Frontend
> and I can have specific application logic therein.
>
> As such parixiscms codebase and myapp codebase are separate.
>
> *- Use of constants*
> e.g. in webapp/controller/FO/Frontend.php,
> $page['content_type'] == 'M'
>
> why not use a class constant?
> e.g. MyEntity::CONTENT_TYPE_MARKDOWN
> it provides a layer of abstraction
> + I do not need to know the actual value stored in db, I just need to
> understand it is markdown
> + The value itself may change, change it only once
> + I can track in my ide where the value has been use for this specific
> purpose
> + One glance at the class, I can know all possible values
> (CONTENT_TYPE_MARKDOWN, CONTENT_TYPE_PLAIN, CONTENT_TYPE_HTML...etc)
>
> *- Use of logical entities*
> I understand F3 provides a mechanism to easily access database entities
> without the need for actual class definitions for each entity. But actual
> class definition for each entity although possibly annoying to generate
> (there are libs / mechanisms to ease that), is actually a good thing.
>
> + You can an overview of the system by looking at the code itself
> + Track usages in your ide
> + Doesn't matter the actual mechanism used (can have PDO, or an
> ORM...etc) - this can be swapped (to a certain extent as long as the
> general API has consistency).
> + Easily track usages - tomorrow you add a property to an entity,
> which elements need to be modified?
>
> - Unholy union between controller and html templating engine
> To be honest, I am not sure of this one, I need to check the code further,
> but here is the general idea.
> Controllers process requests, use entities / helpers as necessary and
> provide a response. Can make things simpler by just providing an html
> reponse but what if I want different sorts of responses? I want xml, or
> json or both or yaml or whatever thingy?
> Same requests, same controller but different output?
> The controller should not provide a response per se, it should provide a
> data representation of the output in a neutral-enough format that can be
> understood and converted into an appropriate format by the bootstrapper (OO
> design, have a consistent interface, hotswap implementations as necessary)
>
> *- Logging mechanism*
> I had minor issues setting up the app (as I told you) but I ended up with
> a 500 error. Would be nice to have application-level logging to let me know
> what is happening. Again PHP-FIG has something on this, an interface, with
> a lots of implementations.
>
> *- Why F3?*
> I do not have experience with F3, so this is a genuine question rather
> than being criticism. I have a deep interest in Symfony and Symfony
> components, and I've been looking forward to building my own idea of a
> micro-framework using these. The only problem being time which is a luxury
> at the moment :/
>
> Will continue to dig in,
> Hope that helps
> Regards,
>
> Yusuf Satar
>
>
>
> On Sat, May 9, 2015 at 12:47 PM, Yuv Joodhisty <locustv2_at_gmail.com> wrote:
>
>> Yea since you are making it a community project, it will work faster when
>> other developers contribute to it and for them to contribute they should be
>> able to go through the codes if you don't have an API yet. And having some
>> good convention would really help the project as well as help you create an
>> API later.
>>
>> Also this year, 2015, is a year specially for PHP developers and a year
>> dedicated specially to PHP since the next major version PHP7 is coming out
>> soon (probably by october or november). It is a complete rewrite of PHP and
>> things to expect are:
>>
>> - there are new operators apart from !=, ==, >= etc
>> - type casting, return types in functions, declarations will now be
>> supported like other programming :D
>> - performance upto 72% can be achieved (yes its very very fast)
>> - amongst others
>>
>> And on top of that the guys at PHP said that we should be able to
>> migrate to PHP7 without having to modify a single line of code. But since
>> it is a migration we should still be prepared for it. So better do it now
>> when the project is still small :P
>>
>> I know that the choice for framework is a personal taste since all
>> frameworks have their own pros and cons but if used well enough a powerful
>> application can be created. I have never used F3 but may i ask why you have
>> chosen F3 for this project?
>>
>> Thanks
>> Yuv
>>
>> On Fri, May 8, 2015 at 8:35 PM, Mohammad Nadim <nadim.attari_at_gmail.com>
>> wrote:
>>
>>> Hello Yuv,
>>>
>>>
>>> On 8 May 2015 at 16:40, Yuv Joodhisty <locustv2_at_gmail.com> wrote:
>>>
>>>> Hey Nadim,
>>>>
>>>> Nice work. I went through some of your codes, i think you should stick
>>>> to some convention if you want to have other developers to help you. For
>>>> example there are places you used camelCase and other places you used
>>>> underscore_case (snake_case).
>>>>
>>>
>>>
>>> Something I rearely do: follow conventions. But to tell you the truth,
>>> before I started with the coding of this CMS, I has a brief look at
>>> PHP-FIG. I found that F3 does not follow PHP-FIG (i may be wrong). So I did
>>> not bother much.
>>>
>>> But you are absolutely right. Some conventions needs to be followed if
>>> we are to make this a community project.
>>>
>>>
>>>
>>>> Also in your virtual host, if you are using apache 2.4 you should use
>>>> "Require all granted" and in older version Order deny,allow & allow from
>>>> all, if i'm not mistaken.
>>>>
>>>
>>> +1 You're right.
>>>
>>> Regards,
>>>
>>
>>
>
Received on Sat May 09 2015 - 11:59:58 PST
This archive was generated by hypermail 2.3.0
: Sat May 09 2015 - 12:09:03 PST