a vague question about processes (procedures) of developping components on CQ, in case of division of roles | Community
Skip to main content
T
TIS_Insight_Tea
Level 2
October 16, 2015
Solved

a vague question about processes (procedures) of developping components on CQ, in case of division of roles

  • October 16, 2015
  • 4 replies
  • 2343 views

I have a vague question about processes (procedures) of developping components on CQ, in case of division of developping roles.

Now, we are planning to develop an website on CQ, on the condition that we take CQ default components without customization as far as possible.
First, we will offer web designers to create HTML mocks, JavaScripts, and CSSs.
After reception of these files from them, we will convert these mocks to actual component resources such as JSPs, or ClientLibraries.

The point I'm worried about is, the designers don't know what CQ is, at all.
ex.
* what kind of default components are there?
* what kind of HTML tags and CSS classes/IDs default components generate?
It means that HTML/CSS of the files created by the designers (,as they like,) may not maches the one of CQ default components.

I'd like to know how CQ developpers solve these issues actually.
This division is basically wrong, and we should implement both designs and components by ourselves totally?
Teach the designers about CQ in advance? (for example, share the list of tags what each default component generates, or something)
Or, We should convert mocks with customization of components? (that is, "without customization AFAP" is not realistic?)

Does anyone have any good tips or standard methods for me?

Thanks,
t.i.t

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Ojjis

    Hello, this was quite an extensive question and I will try to help you answer some of you questions.
    These are some of my tips..

    Default components
    Out of the box there are MANY components. I don't think that it would be wise to try to re-explain them all so I would suggest you look at the comprehensive list of all the default components that CQ/AEM comes with OOB. http://dev.day.com/docs/en/cq/current/wcm/default_components/components.html 
    There is a wide selection of standard ones, ranging from buttons to forums etc. These are all fully functional but depending on your requirements, some components might need some tweaking and there still might be components that you need to develop yourself. However, if you read about these components and still has questions about them, please feel free to ask more questions in the forum..

    HTML tags and CSS classes.
    The components generate a lot of different HTML/CSS. Yet again it would be difficult to list all of them..
    You can control a lot of these in a very simple way by simply overlaying the default ones, without changing any behaviour of the component itself, and just modify the CSS classes and some of the HTML. I think it would be wise to try to teach the designers CQ, not because they will then "get a list of all the tags that the components generate" but to get a better understanding in general of how the client libraries work and the development of components.

    When it comes to the co-operation between the designers and the component developers one needs to think a bit first though.
    You can take a look at the default components and see if they math your requirements. If so, and you don't want to do any tweaking to the standard classes, hand over the classes that the default components are generating to the designers so that they can work with them.

    You can also, if thats the preferred way of working, let the component developers modify the standard components with the required classes from the designers. A GOOD DIALOG between the teams would help a lot (in my opinion a must) here and I would suggest that the people involved in the project gets some kind of education/course in CQ/AEM. Building and managing client libraries of CSS files in CQ is quite easy and flexible so there shouldn't be that much to worry about either way but it sure helps with some background knowledge/education to make things right from the start and also to speed up the process. 

    Implement you own components
    I would say that most projects will need to develop at least some components themselves. Nowadays the requirements of different projects are becoming quite specific and even though there is such a large selection of standard components there might still be something that is not covered. In my opinion though, you could do quite well with only the OOB components and some tweaking of these. But you should be prepared to implement the design yourself and some development at least (even if that only involves tweaking of standard components). 

    I would recommend that you take a look at the requirements for the project. After investigation the standard components (it could be a great idea to see how they are used in the demo "Geometrixx site) together with both the designers and the developers, you then try to map these requirements to what's already present OOB and then you will have a better idea of what you will have to do yourself. Maybe there is also a possibility to change the requirements if there is already some functionality present that could work.

    Creating mocks is in my opinion a great thing when it comes to new components (and for tweaking of standard components). The designers will then create something for 
    the component developers to work with. It's then easy to see what needs to be output from the component itself. This is however often not that trivial and yet again a close dialog between the people involved helps a lot.

    I hope this has cleared some things up for you. 
    There's loads of documentation about the product and nice guides that probably will help you with some of the questions as well.
    http://dev.day.com/docs/en/cq/current.html
    /Johan

    4 replies

    T
    TIS_Insight_TeaAuthor
    Level 2
    October 16, 2015

    I'm glad that you two have helped me although my question was quite extensive.
    Thank you for your reply and prescious informaiton.

    So, I've understood it's very important that developers and designers works on CQ together.
    and now, new questions have come.

    > You can control a lot of these in a very simple way by simply overlaying the default ones, without changing any behaviour of the component itself,
    > and just modify the CSS classes and some of the HTML.
    Does this "simple way by simple overlaying" mean inheritance of default components by "cq:resourceSuperType"?
    If true, it says that I should create a custom component inherits default one, and implement a specific renderer (JSP) script copied from the original one, and finally, modify CSS classes or HTML tags of that replicated script,
    is this correct?
    ex. take a default component, foundation/compoments/breadcrumb.
      This component outputs some <a> tags without any CSS classes.
      Suppose the developers want to use this component which satisfies their functional requirements, but not about visuals,
      things they had better to do are to create a custom component inherits breadcrumb, and override breadcrumb.jsp of this component, and assign CSS classes to these tags.
      (Of cource, developers and designers join in the determination of the new CSS classes with GOOD DIALOG:-) )
      Is this right?
      And two more questions.., 
      it means that the designers sould write CSSs which apply the styles to only "classes", not to specific tags or element IDs/names on CQ?
      Where does the document of CSS classes the default components output exist?


    > When it comes to the co-operation between the designers and the component developers one needs to think a bit first though.
    > You can take a look at the default components and see if they math your requirements. If so, and you don't want to do any tweaking to the standard classes,
    > hand over the classes that the default components are generating to the designers so that they can work with them.

    ex2. take a default component, foundation/compoments/userinfo.
      This component outputs some <li> tags, assigned specific CSS classes such as "user", "profilepage".
      Suppose the developers know it but designers don't, and the developers want to use that component without any customization,
      and the designers can't learn about CQ (in this case, about the userinfo component) with the developers by some causes (ex. a policy of the designer's or developer's company...FYI, this is just my case).
      In this case, how do the designers know what kind of CSS they have to write without something like a list of tags/classes the userinfo outputs?
      Are there any solutions except for handing over of the tag/classlist to the designer or customization of componens?

    Thanks,
    t.i.t

    Ojjis
    OjjisAccepted solution
    Level 7
    October 16, 2015

    Hello, this was quite an extensive question and I will try to help you answer some of you questions.
    These are some of my tips..

    Default components
    Out of the box there are MANY components. I don't think that it would be wise to try to re-explain them all so I would suggest you look at the comprehensive list of all the default components that CQ/AEM comes with OOB. http://dev.day.com/docs/en/cq/current/wcm/default_components/components.html 
    There is a wide selection of standard ones, ranging from buttons to forums etc. These are all fully functional but depending on your requirements, some components might need some tweaking and there still might be components that you need to develop yourself. However, if you read about these components and still has questions about them, please feel free to ask more questions in the forum..

    HTML tags and CSS classes.
    The components generate a lot of different HTML/CSS. Yet again it would be difficult to list all of them..
    You can control a lot of these in a very simple way by simply overlaying the default ones, without changing any behaviour of the component itself, and just modify the CSS classes and some of the HTML. I think it would be wise to try to teach the designers CQ, not because they will then "get a list of all the tags that the components generate" but to get a better understanding in general of how the client libraries work and the development of components.

    When it comes to the co-operation between the designers and the component developers one needs to think a bit first though.
    You can take a look at the default components and see if they math your requirements. If so, and you don't want to do any tweaking to the standard classes, hand over the classes that the default components are generating to the designers so that they can work with them.

    You can also, if thats the preferred way of working, let the component developers modify the standard components with the required classes from the designers. A GOOD DIALOG between the teams would help a lot (in my opinion a must) here and I would suggest that the people involved in the project gets some kind of education/course in CQ/AEM. Building and managing client libraries of CSS files in CQ is quite easy and flexible so there shouldn't be that much to worry about either way but it sure helps with some background knowledge/education to make things right from the start and also to speed up the process. 

    Implement you own components
    I would say that most projects will need to develop at least some components themselves. Nowadays the requirements of different projects are becoming quite specific and even though there is such a large selection of standard components there might still be something that is not covered. In my opinion though, you could do quite well with only the OOB components and some tweaking of these. But you should be prepared to implement the design yourself and some development at least (even if that only involves tweaking of standard components). 

    I would recommend that you take a look at the requirements for the project. After investigation the standard components (it could be a great idea to see how they are used in the demo "Geometrixx site) together with both the designers and the developers, you then try to map these requirements to what's already present OOB and then you will have a better idea of what you will have to do yourself. Maybe there is also a possibility to change the requirements if there is already some functionality present that could work.

    Creating mocks is in my opinion a great thing when it comes to new components (and for tweaking of standard components). The designers will then create something for 
    the component developers to work with. It's then easy to see what needs to be output from the component itself. This is however often not that trivial and yet again a close dialog between the people involved helps a lot.

    I hope this has cleared some things up for you. 
    There's loads of documentation about the product and nice guides that probably will help you with some of the questions as well.
    http://dev.day.com/docs/en/cq/current.html
    /Johan

      Ojjis
      Ojjis
      Level 7
      October 16, 2015

      Hi, glad you liked it. Will try to answer the new questions a bit as well.

      "Does this "simple way by simple overlaying" mean inheritance of default components by "cq:resourceSuperType"?
      If true, it says that I should create a custom component inherits default one, and implement a specific renderer (JSP) script copied from the original one, and finally, modify CSS classes or HTML tags of that replicated script,
      is this correct?"

      Yes, almost. If we take a look at something rather simple like the standard text component "foundation/components/text".
      If you wanted to change some things in this one, the thing you would do is to create a new component with the primaryType cq:Component. Then just add the sling:resourceSuperTye="foundation/components/text".
      If you would skip the part of implementing you own renderers for this component it would simple search for any renderers (depending on the sling request processing, read more about that here:       https://dev.day.com/docs/en/cq/current/developing/the_basics.html ) at the resource super type component. And there it would find the standard ones. However, if you supply your own jsp files, the component would use these instead as long as you include the component you created in a page.

      "take a default component, foundation/compoments/breadcrumb.
      This component outputs some <a> tags without any CSS classes.
      Suppose the developers want to use this component which satisfies their functional requirements, but not about visuals,       things they had better to do are to create a custom component inherits breadcrumb, and override breadcrumb.jsp of this component, and assign CSS classes to these tags."

      Yes, that's what I would do. Just copy the contents of the breadcrumb.jsp and add some classes to the tags.
      The thing here to keep in mind is that when you overlay a component and depend on the functionality on it. Think about what you change in it. In future updates, the component might undergo changes and get updated. If you have made to many alterations and functionality changes to the overlay it might be some work to get it to work again. But if you do minor changes like some css classes etc, this should be less of a problem for you :) 

      "..it means that the designers should write CSSs which apply the styles to only "classes", not to specific tags or element IDs/names on CQ?"

      Well I would suggest this. You can, when you include a component in your page, actually choose a class for the div surrounding the component itself. This would make it quite easy to target very specific elements in different components. Lets say that you have a component named "myComponent". OOB the component would be included with the component name as the class, but what happens if the developers decide that they want to refactor this component? Then it will get a new classname and the css that the designers have written would not be corectly targeting the components parts.
      What you can do here is to do some alterations to the include statement of the component on the page (read more about this here for some better explanations http://forums.adobe.com/thread/981240. Then you could end up with something like this:

      <div class="myChosenComponentClassNameFromComponentJsp">
      <!-- lots of nice code in my component-->
      <a href ="#"> A link to nothing </a>
      </div>

      In this case, it's easy to target the <a> tag with the css and the use of the classname for the component and you wouldnt not have to worry about destroying the look of something else on the site. Regarding the usage of Id selectors in CSS, I neither recommend this nor prefer it for numerous reasons but thats not a CQ/AEM question ;)

      "Where does the document of CSS classes the default components output exist?"

      I'm not sure there is such a list. My suggestion is to look at the code and see for yourself. And as you've mentioned already, if you overlay you components it's not a big issue since you will have control of most things anyway.

      ex2. take a default component, foundation/compoments/userinfo.
        This component outputs some <li> tags, assigned specific CSS classes such as "user", "profilepage".
       ......
      tags/classes the userinfo outputs?
        Are there any solutions except for handing over of the tag/classlist to the designer or customization of componens?

      A good question, I don't see how there could be another way then to actually communicate here but thats just my opinion. Also while doing that there sometimes might come up that things might need to be altered in the component code and changes need to be made. This because the CSS styling can only fix that much in the end. Maybe some code changes would make life easier for the designer and the whole project. Then the designers don't need to know anything about CQ but might be able to add some valuable comments to the component developers in general about the output of certain components.

      Best of luck
      Johan
       

        O
        Ove_Lindström
        Level 6
        October 16, 2015

        After 18 months as architect of a CQ5/AEM initiative and a lot of components and developers later, I will share my thoughts in this matter.

        First about the design. Designing the look and feel of the components is a process that can easily be done by a UI designer without much knowledge of AEM. They create a mock that is a base for the front end developers that creates the markup. However, our experience is that if the designer and the front end developer can cooperate, the process is a lot faster. What is absolutely crucial is that the designers is getting knowledge about the component model and the Sling framework, so that they can design a component with different views and functionality.

        When we develop components with a UI designer, we tell them what base functionality we already have implemented in our base client libraries that they can take advantage of. We also ask them to group their UI functionality in groups so that they just have to describe it once. A bit like defining a use case and then just refer to it. If the component should have the ability to have different look and feel or have different behaviour, that also needs to be taken into consideration. Sometimes, you have to convince the designers that the same component can't be used, but that you need to have one component of template defining the data set and other components that views them, such as a listing component. We call components that does not really contain any data but just output other components/templates data "lenses".

        What we also has done is to use a strict component paradigm, the same way as Adobe does with the foundation components and their own WCM components. Each component holds their own client library with js and css (often described in LESS) and their own markup and sling selector descriptions. No code should be used from other components. Obviously, you can have common client libraries that defines javascript functions or base css, but you then make sure that your components have relations to them. We have chosen to group components that can't be used without each other in common client libraries. When a site then needs the component, the relation is defined in the design client library. In this way, we create a component library much the same way as you would do with java classes.

        What is equally important, imho, is the author mode ui. We strive to have the components look as much as possible as they will do n the published environment. But sometimes, that is not possible and it would make the life of the authors that creates content a bit hard (or a complete hell if you do it wrong). So you need to know where to put your drop targets, where to have in-line editing, what properties that should go into the design dialogue and what to put in the component dialogue. And what events to catch and how to assist the authors the best way you can. Most of the time, there are "hidden" information in the component that has an impact on the look and feel, but is not visible. Those are important to find and then we get back to the conclusion that the designer and the developer needs to cooperate. A good frontend designer that knows his way around html, javascript and css might send you a bunch of html-markup-files, one .js and one .css... And then you will have a hard time cutting it up. It is important that the designer know about the quirks and bells of CQ5/AEM and learn to deal with them.

        Anecdote time... I had a UI designer that got furious when he/she found out that we had added html elements that was not in the original markup and that we had messed with his css... Avoid that.

        And to be frank, most of the time, a good UI designer could easily be thought to do the markup from within CRXDElight...

        I hope that this was a little helpful.

          Terms & ConditionsAccessibility statement

          Loading footer...