Replies: 1 comment
-
Little HistoryOkay so JCB was originally designed as a back-end builder for my own purposes. Then as I took more projects I needed more and more front-end help, to speedup my development, this then birthed the dynamic-get, custom-admin-views, and site-views. So we added data in the admin area, and on the front we just displayed them. Then I saw the need to add a edit view to the front-end. At the time Joomla itself was really just porting the back-end classes to the front mostly and so I did the same. Then we had a need to decouple the back-end classes from the front-end, so at this time the compiler really stepped up to literally setup a whole new "cloned" edit view of a back-end edit view... this was a big achievement at the time specially since all the permissions and stuff was now working back and front for any edit view in JCB. Permission has been at the hart of JCB's development from the start. So that instead of hard coding who can see what and do what... we used the Joomla permissions to set this dynamically for each installation of our components as per client purposes. Current StateSo at this point we had a working stable front-end edit and display added to the original back-end. But to work with this you needed to know a number of things about JCB.
RealityAll font-end forms produced by Joomla's API will look like this raw result without custom styling on the front-end. Yet because I really don't have time to write my own CSS, or JS maintained front-end library I made it possible for developers to choose what they want to use, by adding a library area in JCB. So you can use bootstrap, uikit... or any number of other options with no limitations. This resulted in a front-end that will never look the same, and so ensure that all components build with JCB does not immediately to the end user look like a JCB build project. So we had the hand crafted front-end (from the end-users perspective) and a fully automated wire-frame that literally does all the hard work to bring the data and store, validate, authenticate... secure the data... and you just get to focus on the eye candy in the front, and in the back-end your component looks so much like Joomla that the end-user can easy get to work as everything looks and feel familiar. Not to mention that all views, templates and layouts can be overridden in the normal Joomla way as with the native components of Joomla. FutureYes we looked at improvement of this area, we even started on an assistant. Then we did a pole with those developers who where using JCB everyday for large projects... that I knew about. I asked them what they thought of automating the front-end as we did with the admin area, and what they thought of an assistant. Their response was not what I expected... as you can see the assistant branch is here on Github... but has stopped. They said to me they have no use-case for any of what I was doing with the assistant, but would instead want to setup a component front and back from a flat-file instead. Like a yml or json type file that you can give JCB and it builds a component fields, views, and stuff straight from that. This was a moment where I saw the future of JCB... a moment I could see a conversation with a client... like notes get converted to a json... and then in seconds have a whole generic component ready for the final touches. This will speedup development even more then what we have now. They said that the fact that JCB has so much freedom on the front-end and has not forced an specific direction has been a stunning move, and what they would never what to see change. Yet they agreed that we can improve the front-end forms area... and in fact the idea to decouple the front-end forms to be able to post to multiple back-end tables from one form was also born from this investigation... and is being worked on as a pro-member feature. JCB Target MarketThere is about 200 active developers (could be different developers everyday or the same) using JCB every week from what I can see. Very few of them are active in the forums, this tells me they are able to use JCB without help from others. My best guess is that our market is mostly experienced developers at this point. Road MapWe need to take JCB to Joomla 4, therefore we can do only minor changes here and there to improve the edit view in the front-end, but no major redesign or change that will go beyond a few hours of my time. Because J4 will indeed bring with it so many new options that I can't begin to list them. Joomla 4 does indeed look like a major step forward for Joomla. So besides little odd bugs here and there... JCB is getting ready for J4 trying to be ready in June/July 2021 Hurdles and WhyWith help of the funding coming in from the Pro-Members and other donations... which is very low at this time. Before Covid-19 I was fully booked nearly 6 months head (with JCB development), but now things are moving slow... I have in fact started taking Jobs in the C/C++ and BASH/Shell world, working with Servers, Networks, Deep-backend stuff... as the JCB or Joomla business is very quiet at the moment. Conclusion@EvDoorne, I think you are right that JCB can do with a better front-end development path, maybe the flat-file initiative that I mentioned above will help resolve some of the setup issues, that are not that obvious to novice JCB users. Yet I would direct your attention to yootheme templates and custom CSS and JS solutions for now. Once we have landed on J4 we can pick this up again.
|
Beta Was this translation helpful? Give feedback.
-
Adding a more generic note here form a novice user. My company has develped a number of components now with JCB and we have consistently run into issues with frontend editing. We use Helix Ultimate for most of our Joomla! work and found almost never this to properly work with JCB generated components in frontedn views. In a number of occasions, we had to revert to the use of the Protostar template in order to get frontend (editing) working at all. The above more or less explains in-depth why. Out of the box, JCB generated components will not perform proper frontend-editing at all with user installed templates. This kinda breaks end-user expectations.
Of course this is due to our limited comprehensio of how JCB works. But this is also something so basic, I feel this needs to be resolved in a proper manner as it holds back non-experienced users from getting the desired end-result: a component that will work on 'any' template (I know, that is a fiction but I think you know what's being meant here).
Adding an additional (backend or frontend template) dependency, in my opinion, only complicates things more and adds more options to introduce problems. Perhaps we should just add (as in: copying) the necessary css and/or js files to the component to ensure things work properly. Linking to another template, even a base package template, which' existence is not guaranteed nor enforced, may be data-efficient and maybe even very 'dry'. But I'm sure it's not very fail-safe and will not help in creating components that work standalone with minimal issues.
Bottomline: if you need certain files to be included: include them.
Beta Was this translation helpful? Give feedback.
All reactions