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 - 10:30:59 PST
This archive was generated by hypermail 2.3.0
: Sat May 09 2015 - 10:36:03 PST