Hello Jeremy,
First of all thank you very much for Xway 1.0 it is an excellent product, very pleasant to use. Really a very good work 
I just discovered the use of Exhibeo, also a great product. Its integration with Xway is very easy and works perfectly well. I also noticed its “component” extension.
I come to my question: is it possible to create my own components for Xway and save them to reuse them in other projects?
Hi Bruno,
Yes, you can.
There is a section called “Component format” in the Components chapter of the user guide.
Yes but it’s a little bit short. Anyway Try-error-correction would bring me toward success 
Looking inside an Exhibeo component (secondary click, Show Package Contents in Finder) is probably a good way of seeing a concrete example of their construction. Off the top of my head, I know the Bloxx theme uses everything (e.g. both head and body).
Expanding a little on what’s in the user guide, markup.html will look something like this:
<head>
Things you want put inside head on the page
</head>
<body>
Things you want put where the component box is on the page
</body>
The elements you put inside body should not have IDs to avoid conflicting with multiple components on a page or IDs that Xway may use, with the exception that any one element can be given an ID that matches the contents of the outputId file. Xway will substitute this with the “Name/ID” given to the component.
That part probably doesn’t really affect you making components for your own pages but useful to know in case you want to make components to give to anyone else.
The description and info files are what appear in the inspector, as shown here (the latter shown by clicking on the former):
I think the rest is well explained in the user guide. Hopefully that should be enough to get you going but feel free to ask any questions you may find as you go.
Hi @simonmanning Thanks for your reply. I started looking at the Exhibeo component structure and am currently “tinkering” to see if I can build a layout to display blog posts (with markdown to html transcription and link to images). I think I will definitely have some questions.
First unsuccessful attempts, my component is not loaded by Xway, however this does not generate any warning. And here is already the first question (it did not take long): I create the component by zipping the required files then I change the zip extension to that of the component for Xway, is this how it should be done?
It’s not a zip, just a folder - macOS packages are just folders using path extensions that apps have registered.
Instead of zipping the files, make sure they’re in their own folder together and then rename that folder to yourthing.xwcomponent. Of course “yourthing” can be anything you choose.
Thank you very much for your answer, first challenge succeeded, I have my first operational component.
I’ll try a second question (no more for today, I don’t want to abuse; don’t hesitate to tell me when it will be the case, I won’t be offended, I don’t want to take up too much of your time with beginner questions): how can I define a size for the box that will display the list of my blog articles and then the selected article according to different screen sizes? Let me explain: I would like to not display as much information around the article depending on the screen size, for example the author’s name, categories and tags will not be displayed on mobile but on tablet and computer. I thought about container queries, would that be a good principle?
Container queries could work, if the width of the containing element is the thing you care about, which seems logical. My initial thought was media queries but container queries are probably a better fit.
Hypothetically, if your structure is something along these lines:
<article>
<h3>Some title</h3>
<p class="metadata">Some Author - category - tag1, tag2</p>
<p>Some blog content</p>
</article>
You could probably use this (hide elements with the metadata class if their container is less than 500px wide):
@container (max-width: 500px) {
.metadata {
display: none;
}
}
Obviously it can be more complex but I think that’s the general idea. Something you might need to be careful of is that if you are targeting spans within a paragraph, the container would be the paragraph and maybe that is just the width of the text, so might trigger hiding it if the author’s name and list of categories/tags happens to be short enough (I don’t know).
Thank you very much again for your answer. Yes, that’s the idea. I’ll be able to have fun with all this. I’ll keep you informed of the success or not of the project.
I’m not a developer (I’m a psychologist who will soon be retiring) and I don’t want to take the work of developers, so I won’t sell my components, I say this to be clear. I build for fun and to compensate for the temporary absence of what I need. I’m also waiting for a developer I know 
(I hope he recognizes himself) to come forward so that I can get the components I have and need from him.
Something to also consider actually is that @container became broadly available in browsers in February last year. While this means it is will almost certainly be available on any up-to-date system, it might not be available on things like older Android devices, end of life (before February last year) iPhones, etc.
If you’re likely to have many users visiting your website with older Android devices especially, it may be better to use media queries to ensure those devices get the slimmer view you’re aiming for.
That works similarly, except the size is the viewport (whole page) width instead of container width:
@media screen and (max-width: 500px) {
.metadata {
display: none;
}
}
very good point, not being a professional in the IT field, I always think like a user and not about users.