[#1929] - Support new MVC views in com_menus
- Closed
- 24 Sep 2013
- Medium
- Build: master
- # 1929
- Diff
- elinw:menunewmvc
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Well I thought about the which first option and I know why you say that,
but the issue is that then for refactored extensions we will always end up
going through the proxies, though I guess as you say if we remember in the
future we can always switch it back. Not something I feel that strongly
about. Maybe when half of the core is refactored we could switch? What do
you think?
Basically I'm trying to do minimal changes just to solve this problem not
to refactor but you're probably right that it makes sense to do so.
Elin
On Sat, Sep 7, 2013 at 9:24 PM, sovainfo notifications@github.com wrote:
Consider this bad code for the following reasons
- testing existence twice, once with a cleaned path, once without
- mixing JFile::exists with file_exists
- cleaning should be limited to $base and also done for file_exists
this should be using file_exists only, no need to include JFile
it should use an if else construction to avoid test the 'same' thing twice
Assuming at the start there are more in views than in view the first test
should be views later version can swap
or to promote the new model start with view—
Reply to this email directly or view it on GitHub#1929 (comment)
.
As soon as content and tags use the new MVC change the order. Consider them the most important.
garyamort
-
Consider this bad code for the following reasons
this should be using file_exists only, no need to include JFile
it should use an if else construction to avoid test the 'same' thing twice
Assuming at the start there are more in views than in view the first test should be views later version can swap
or to promote the new model start with view