Improving the Hippo CMS developer experience

[Jeroen Reijn]

Hi all,

for one of the upcoming Hippo CMS releases we want to further improve the experience of developers working with Hippo CMS. 

Currently, Adrian and I are gathering input from everybody we know (both on- and offline) so that we can come up with a concrete list of areas that need our attention. 

We've gotten some feedback in the past, which is already on our list, but it's extremely valuable for us to hear from you, our community, what we can do to make you enjoy working with Hippo CMS even more. Out of your feedback, we will try to get the most important areas, which we will then try to address in one of the next Hippo releases.

Bear in mind you don't have to be an experienced Hippo Developer to give this feedback. If you're new to Hippo, your feedback is just as valuable!

So our question is: 

What's the most important thing you want to see improved/fixed in the next Hippo CMS releases?

We're looking forward to your feedback, so fire away!

Gr,

--

Jeroen Reijn
Hippo

Amsterdam office - Oosteinde 11, 1017 WT Amsterdam

Boston office - 745 Atlantic Ave, Eight Floor, Boston MA 02111, United states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

http://jeroenreijn.com | @jreijn | http://about.me/jeroenreijn

[Brian Snijders]

Hi Jeroen,

Nice initiative and good to address this. Two suggestions by head:

1) By default, integrate pluggable Spring Security support in the HST. Almost all of our implementations use some sort of security. Since HST is already Spring-based, this shouldn't be too hard. In the case security is not an issue, you can just have an empty securityContext, not doing anything and simply forwarding requests down the filter chain.

2) Break down hippoecm-extension.xml files into separate parts. Then, to minimise impact on repository initialization mechanisms etc, you can for example aggregate the partial XML's into one big hippoecm-extenstion.xml in the Maven build pipeline, e.g. during generate-(re)sources for example. This makes merging and coding with larger teams easier. I know this has been discussed between Ate and Reinier on the mailing list, and from our side acknowledge that the current way or working with the hippoecm-extension.xml can be time consuming. For large projects we solve this now by having a gatekeeper in the team, who coordinates bootstrap usage, to minimise merge conflicts/impact. But, actually, imo it's more up to the product stack to support me in this as a developer.

Happy to think along though if you want to sit down over this someday! Again, a good thing this is addressed, looking forward to it.

Good luck :),

Brian

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at http://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

Met vriendelijke groet,

Brian Snijders
Software Engineer
http://about.me/briansnijders

Finalist -  open IT oplossingen
Rotterdam - Eindhoven - Maarssen
http://www.finalist.nl

Telefoon 088 217 08 43
Mobiel    06 455 40 083

[Wim Lustenhouwer]

Hi Jeroen,

Junior developer here. And generally the most of my time spent developing is in debug mode. And I generally have a hard time finding some of my beans set to a request. So as an RRC i’d propose the following: decouple the HstRequest from an HstComponent. Here’s how i’d see this.

Any hstComponent will set a baseBean. So in the doBeforeRender class, instead of setting an attribute to the request. You’d inject a bean instance to the baseBean. Something like

// superclass has BaseBean BASE

doBeforeRender(this, that) {

super.doBeforeRender(this, that);

Thing thingToProcess = doSomethingwithDocument(documentSetWithConsole);

Base.setBean(thingToProcess);

}

As for the advantages:

While debugging, we can call a getBase which contains solely the attributes set to the current request, instead of having to debug the entire request. Secondly, handling request logic is done in basically every component made in the current situation. Catching this will greatly reduce the repeated code.

Secondly, I read my command line in run-time. And it’s flooded with INFO’s and WARNS on initial build. It’d be great if these didn’t go to the command-line and isntead to some log, leaving the command-line free for Errors and stacktraces.

Good luck,

Wim

[Joost O]

Hey Jeroen,

I mentioned it before, so just as a reminder.
It would be awesome if the scxml was configured in a pluggable way, so we can easily just add something to it, instead of having to configure the whole thing in one place as a giant xml.
Especially for module creation this would be useful.

Regards, Joost

[Jeroen Reijn]

Great stuff all! 

I'm really appreciating the feedback I've been getting so far. 

Adrian and I are putting it all together in a list so that we can prioritize the issues.

Keep it coming!

Gr.

Jeroen

--

Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at http://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

Jeroen Reijn
Hippo

Amsterdam office - Oosteinde 11, 1017 WT Amsterdam

Boston office - 745 Atlantic Ave, Eight Floor, Boston MA 02111, United states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

http://www.jeroenreijn.com | @jreijn | http://about.me/jeroenreijn

[Brian Snijders]

Probably a low level repository access shell... for example, by using Spring Shell (https://github.com/spring-projects/spring-shell). Currently I'm building a small proof of concept for this.

Why would it be useful?

- to execute JCR operations which are load-intensive, like importing big sets of content/images/assets

- to easily navigate the repository, probably using a HATEOAS-style service

- to perform bulk/batch operations, which need more feedback on processing than just the "magic spinner icon" in the console (when performing a lot of changes)

- to run groovy scripts against the repository, without the need of CMS access and without littering the CMS with scripts which are clearly not update and/or developer scripts (e.g. custom maintenance scripts etc.)

Especially the improvements for import/export and traceability drive me to build a POC for this :)

Kind regards,

Brian

[Jeroen Reijn]

Hi Brian,

sounds interesting. Did you evaluate jcr shell?

https://forge.onehippo.org/gf/project/jcr-shell/

I think it needs a little bump to the latest versions, but AFAIK it will work even with Hippo10.

Jeroen

[Brian Snijders]

Hi Jeroen,

Yes, I've checked jcr-shell before. It seemed a little discontinued back then, but if you say it still works with 10 after a bump, clearly it is not :). I'll look into it for my poc!

Thanks,

Brian

[Brian Snijders]

FYI, my spring-shell works :)

I've just use the repository-connector to login over RMI. Currently navigating my content repository like a filesystem!

[Jeroen Reijn]

Nice! :D

[Alexandru Ionescu]

Hi guys,

One of the biggest topics we also face is bootstrapping. From our side +1 for breaking down hippoecm-extension.xml so multiple teams can work on the same instance of HippoCMS.

It would be nice to also have a progress indicator when importing / exporting content and configuration between environments ( currently behind a loadbalancer we get a timeout and are kicked out of the CMS Console, but the process runs in the background and you can only see that if you check the JVM and CPU of the server ).

Also it would be nice to have more "out of the box" solutions for providing different teams the possibility to create document types and templates without coding Java and recompiling / redeploying. We are already working on this and we have a concept, but we could use more advanced features from the CMS.

Best regards,

Alex

[Ard Schrijvers]

Note that I have been working on this already as well : I call it
'bean-less scripting support'. I've already created a patch which
covers 90% of the requirements already, see in [1]. After I have
finished [1] which is close to low hanging fruit, it will be possible
to add new document types in the CMS, and use them directly in your
FTLs. Something that is not in that issue description, is that I also
want to check whether we can decorate the FTL bean support so that if
for example ${doc.title} cannot be found (because the class does not
have #getTitle) that we try to fetch
${doc.property['myproject'title']} : Note that this latter is already
supported in jsp and FTL.

I also did let Reijn know I think we should included [1].

Hope this is in line with how you think about it

Regards Ard

[1] https://issues.onehippo.com/browse/HSTTWO-3197

>
> Best regards,
> Alex

>
> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hippo-communi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.



--

Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
Hippo USA, Inc.- 745 Atlantic Ave, Eight Floor, Boston MA 02111,

[Jeroen Reijn]

Hi Alex,

see my comments inline.

On Thu, Oct 22, 2015 at 8:48 AM, Alexandru Ionescu <gigi...@gmail.com> wrote:

Hi guys,

One of the biggest topics we also face is bootstrapping. From our side +1 for breaking down hippoecm-extension.xml so multiple teams can work on the same instance of HippoCMS.

Great! Thanks for letting us know! If others agree as well, please +1 it. That would really help.

If there are other things that you've seen before don't be shy to just say you agree with the person, so we can see what the biggest impact will have.

 

It would be nice to also have a progress indicator when importing / exporting content and configuration between environments ( currently behind a loadbalancer we get a timeout and are kicked out of the CMS Console, but the process runs in the background and you can only see that if you check the JVM and CPU of the server ).

Yeah I see where you are coming from with this. Especially for larger XML imports/exports.

 

Also it would be nice to have more "out of the box" solutions for providing different teams the possibility to create document types and templates without coding Java and recompiling / redeploying. We are already working on this and we have a concept, but we could use more advanced features from the CMS.

This is an interesting topic. If you have time somewhere I would love to talk with about your ideas. Perhaps we can do a Google Hangout session about this topic and your ideas? I would love to know more. If you want you can add me with j.r...@1hippo.com.

Thanks so much for your very valuable input so far.

[Rick Beemsterboer]

Hi Jeroen,

Something I ran into (again) this morning: the lack of inheritance of the editor templates in the document types. It would be nice if the editor templates had proper (any?) inheritance just like the nodetype bit of the document type definitions. 

Cheers,

Rick

[Jeroen Reijn]

Hi Rick,

I think we already solved that with Hippo 7.9. The document types have true inheritance now AFAIK.

I think you are ready for an upgrade :-)

Jeroen

--

Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at http://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

Jeroen Reijn
Hippo

Amsterdam office - Oosteinde 11, 1017 WT Amsterdam

Boston office - 745 Atlantic Ave, Eight Floor, Boston MA 02111, United states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

http://www.jeroenreijn.com | @jreijn | http://about.me/jeroenreijn

[Rick Beemsterboer]

Woops! Well good that it got fixed! :P

Rick

---

From: hippo-c...@googlegroups.com <hippo-c...@googlegroups.com> on behalf of Jeroen Reijn <j.r...@onehippo.com>
Sent: Friday, October 23, 2015 13:15
To: hippo-c...@googlegroups.com
Subject: Re: [hippo-community] Re: Improving the Hippo CMS developer experience

 

[jan.de....@gmail.com]

Hi Jeroen, concerning inheritance i've a question that fits the topic of enhancing the cms experience.

I've a customer that can add documents containing pdf's and images. He add's hundreds of these to current documents. These "appendixDocuments" come in three flavors so can have one of three images.

Ideally i'd like to give hime a query so he can select "create appendix doc A", or "create appendix document b" etc with the correct image preselected. I can figure out a solution based on current inheritance functionality, but maybe this would be more easily resolved when a document created in the cms could inherit another document, and immediately have all fields set on the newly created doctype. 

This is based on my assumption that inheritance works on the java-level, but not on the cms level. If I inherit a document i still have to set all it's fields in the cms.

The question would be, is my assumption correct, otherwise this is some food for thought for your improvements.

Op vrijdag 23 oktober 2015 13:15:57 UTC+2 schreef Jeroen Reijn: