3

As we (two volunteers) are going to develop a component with some features mirroring (part of) the processes going on in the (non-profit) foundation, I was wondering if there would be a rule of thumb to determine if one develops part or all of the component in the front-end part of Joomla or in the administrative backend?

If it were a public website then the decision of front-end versus back-end component development would be more of a clear-cut decision. One would probably want to show things in the front-end whilst managing the front-end data in the back-end.

But this is most likely going to be an intranet website within the foundation. Where normally the back-end would manage things for the front-end, in this case there's not really a website to manage, but there are processes within the company (revolving mostly around people or contacts) to manage.

If it were only my choice, I would probably be satisfied building the features in the administrative backend only, using the default style. It would probably save some time.

Though it might be the foundation would like more of a custom styled experience. So in that case, I should probably choose the front-end over the administrative back-end? Or develop the component for both front-end as well as for the back-end.

Still, regarding my question - "How to decide developing a front-end or back-end component?" - are there any important pros or cons choosing the administrative back-end over the front-end or vice versa?

Improve this question
2
  • 1
    How about a role based approach to ACL: magazine.joomla.org/issues/Issue-Aug-2012/item/… magazine.joomla.org/issues/issue-sept-2012/item/…
    – iamrobert
    Commented Jan 6, 2018 at 13:55
  • 1
    If you're struggling to decide whether you should be writing a front end or back end component, then maybe you really need to be asking whether Joomla is the correct choice for your project.What does Joomla bring to the table? Sure, you get some user management, a framework to structure your code and some utility functions. Maybe consider something like Laravel.
    – Dom
    Commented Mar 7, 2018 at 2:33

2 Answers 2

Reset to default
1

How itoctopus said, every answer on that topic is likely to be subjective.

You can highly customize the behaviour and looks of your extension in the backend (Easyblog, Akeeba etc.). You don't have to do everything with the given Joomla tools and limitations. You even could create a different admin template for emyployee user accounts.

IMHO I would locate most code of my component in the administration part and would just call controller, helper, model files from the frontend if needed. (Keep security in mind!) I don't see the need to have duplicates of backend features in the frontend. (Don't repeat yourself.)

For example, you could have customer management in the backend and could load the same management in the frontend for a user account feature, excluding some admin functions like "delete user" by checking ACL access rights.

Another question is the usability for the end user, is he / she doing other stuff in the frontend which could relate to your component and if, does it make sense to locate that in the admin area with a different UI or wouldn't it be streamless within the frontend look and feel?

For intranet solutions I would provide user features in the frontend area and would use the backend just to manage admin aspects of the component / system. Therefore it's easier to manage menu structure (you can use SEF-URLs here), modules and com_component pages like a guideline page. And IMO the frontend is easier to extend with new, yet unknown features or 3rd-party extensions.

Improve this answer
1

This is an interesting question, and any answer you will get to your question is likely to be subjective. I would personally go with the backend, because, IMHO, content management tasks must be restricted to the backend. This will give you a bit more flexibility in case the company wants to display public things on the frontend (say for all company employees).

If you go with the frontend, you are essentially limiting your options in case requirements change.

Improve this answer
1
  • 1
    I agree about the question and as such answers being somewhat subjective but it seemed more 'efficient' asking this kind of question (though I've done my best not making it too vague). It would be most helpful if you could explain the flexibility or the limiting your options part?
    – Wieger
    Commented Nov 6, 2017 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.