App idea: Content Type Manager

Applications
#1

Hey guys :slight_smile:

I’m starting to create an application for Enonic with the purpose of helping editors / developers with the management of content types.

I’ve only worked the last weekend on it, so it’s in a very early stage of development.

The reason for this post is that I’d like to share what I’ve created by now and also check if you guys think that it’d be a great feature to have, helpful for the community, etc…

As I’ve said, it’s still in a very early stage. I’ve just recorded it to show the main idea behind the app that I’ll be working on.

I’m open to receive suggestions and everything, so feel free to comment on this post your opinions about it!

Thanks!

6 Likes
#2

Super cool :slight_smile: :+1:
I guess It would be useful to support editing of existing content types as well (like paste your existing cty and start editing).

1 Like
#3

Nice to see that you liked it :slight_smile:

Yeah, I’ve started to implement that feature!

My plan for this app is to let the user manage everything related to content types. In the video I showed a simple creation, but the plan is to have a full create, read, update and delete.

Where am I expected to be updating the development process of the app? Can I post here the updates about it?

1 Like
#4

Awsome work, Bruno. No problem to post the updates here :slight_smile:

1 Like
#5

Hi @tsi, @mer and everyone who might be following this post!

I’m really happy that you enjoyed my idea for this app, therefore I’ve continued and will continue to work on it in my free time!

Here’s an updated version of it:

From my point of view it is a big improvement since the first one I showed when I created this post. What do you guys think?

I have a lot of points / features that I’d like to improve / implement. I’ll list some that are currently in my mind:

  1. Handle sets (field set, item set and option set);
  2. Insertion of mixins and x-data;
  3. i18n translations for each field;
  4. Change some “default” text input to a select input since it sometimes needs to have its content from a set of values;
  5. Add images (as a helper just like this one for example) for each input type;
  6. Validate the removal of a content type before actually removing it;
  7. Add a duplicate button.

It’d be awesome if you can give me some ideas of things that, in your perspective, are worth to be added.

Thanks :smile:

2 Likes
#6

Focus on helping with quality

If I were you, I would put my focus in helping developers create better quality data models, and content creators creating better quality data.

And that is not easy!..

Better data models

Here are some points where I think developers often can improve, when creating models:

  1. Not making enough fields mandatory (<occurences minimum="1" maximum="1" />). I think this should be your default setting
  2. Are your field labels immediately intuitive for content creators? There is maybe not much we can do automatically here, but maybe some text to guide data modelers to create more intuitive labels, and help texts.
  3. Too complex models. Sometimes data modelers create too complex nested models. There are cases where nested levels can be merged into one, for a simpler model. Can we analyze the model to alert data modelers to these cases.

Better quality data

Here is a chance to go beyond what XP provides. You can add configurations that will do more complex validations on the data, and provide a part or Thymeleaf-fragment that outputs the results of that validation when viewing the page in mode="edit" .

This can be modeling dependencies between fields in some new way.

I don’t know if this makes sense, but it’s just some thoughts I’ve had. :slight_smile:

– Tom

1 Like
#7

Hi Bruno. Great progress! We have a meeting tomorrow where we will look at this and give you more feedback :slight_smile:

1 Like
#8

Hi Bruno. This is definetly starting to look good.

A few questions:

  • How/where do you store the content types? In a local app filesystem project?
  • It is not clear for us how the editor connects to the file system?

As you say, one would need full support for sets and nesting of inputs.

My biggest request would be that you “hide/minimize” the XML field, as that is not really needed uness someone wants to see it/copy it.

1 Like
#9

@breisfm Can you share the code on Github?

2 Likes
#10

Hi @tsi.

  • The generated XML is stored in the content-types folder (src/main/resources/site/content-types). Besides that, I use a custom repo that I named as “content-type.manager” to store some configurations of the tool and also some JSON data for each created content-type:

    image
    image1538×413 23.6 KB

    This current approach works great, but currently we can’t manage content types that weren’t initially created using the tool. Being able to edit previously “hand-maded” content types is something that I have in my mind and want to implement in near future.

  • To manage files in the file system I’m using a combination of some functions in this library created by @rbrastad and the I/O lib

  • I’ve implemented some updates related to the previous version that I’ve shown you guys, and there I have a “hide/show generated xml” button as you’ve requested :slight_smile:

I hope to have another update that is worth sharing this next weekend!

Thank you Thomas.

#11

Hi @tom

Since I’ve rushed to implement some features to see if my idea was worth it, the code is a bit messy at the moment. I’ll refactor it a bit and also document some things before uploading it. After that I’ll share the code on Github ok?

Thank you!

1 Like
#12

Creating a repo for storing metadata related to building content types sounds like taking this in a wrong direction imho :thinking: Since this is mainly being developer tool, beyond the content types itself - it should be stateless.

How about just accessing, loading and writing files directly using File system access API?: New in Chrome 91: File System Access API improvements, Google IO, and more - YouTube

The app could then find and list all existing Content types, as well as create new ones simply by using the local file system :smile:

Another question, are you using the low-level Java API for creating and validating content types? AFAIK this should be capable of both parsing and exporting XML definitions.

2 Likes
#13

Hi @tsi,

After some thought, I couldn’t agree more with your suggestions… Thanks :slight_smile:

I worked a bit more in the content type manager tool and things are starting to go into the right direction in my point of view:

I completely changed the way I was seeing / trying to solve the problem. Now the tool is basically a way to go from XML → JSON, mutate that JSON using a GUI, and then go back from JSON → XML.

I was facing some problems, mainly because most of the libraries that performs that conversions are not robust enough. The main problems were:

  • The transformation defined as the composition of the transformations XML → JSON → XML wasn’t preserved as the identity function;
  • The transformations weren’t preserving the order of the elements.

After some struggle I was able to find a XML <–> JSON lib that worked perfectly.

As you can see I followed your suggestion to use the File System Access API :+1:

The only problem that I see is that it’s not currently supported by some browsers. What do you think?
image

There’s still a lot to work on, but I’d like to ask for some suggestions. @tom already gave me some good ones that I’ll be implementing in near future. Thank you Tom.

@tom, I hope to post the code on GitHub by the end of this week. I was expecting to release the code sooner, but since the @tsi suggestions, I started to mess around with a lot of different ways to attack the problem and therefore wasn’t focusing on the quality of it.

Thanks!

1 Like
#14

Don’t worry about Browser support.

Your target audience is developers, and they will know how to get one of the supported browsers if they don’t already have it.

Personally I use progressive enhacement when I develop applications.

So I would create a base layer in my application that maybe output the result in the browser. And then I would enhance it to use the File System Access API for browsers that have support for it (by feature detecting it).

If you are not familiar with progressive enhacement, but want to get started using it. I recommend the Resilient web design podcast. It is only 7 episodes, and especially episode 5 and 6 contain really good information.

1 Like
#15

We just had a roadmap meeting, and had a look at your app. This is so cool :slight_smile:
Looking forward to seeing this launched on Market.

1 Like