Hi,

Great idea. How about Sling Starter/ Loader / Bootstrap ?


Regarding building a real app with Spring I would like to go through
that process (be a guinee pig). We would like to use the content
repository in a Saas like app using micro services.

The content would be written via one service via Oak API and edited by
the service desk via Composum, and read by other services also via Oak
API. 

My plan is to write a docker compose file that simulate the multiple
services. One of the service will have Sling + Composum installed.

I'm planning to use the RDBMS back-end for Oak because we have expertise
with PostgreSQL.

Some things that I would like to make test/know before going into
production:

- reading and writing from multiple services works ok - check delay,
caching, etc
- editing content via Composum works properly
- procedures on how to deploy content updates to production (FileVault
maybe)
- how to get content from production to staging to facilitate testing
- how to deploy and update our single page applications that consume our
API
- how to deploy/update translations for content

I know I have quite specific needs that might not fit into general
norms, but the needs are real and I am willing to document and share the
process and all the code samples. All I need in return is some guidance.


Regards,

On 03.10.2017 13:11, Carsten Ziegeler wrote:
> I think we can improve the user experience with our launchpad.
> Let's start with the simpler issue:
>
> Right now if you start the app and try "too soon" to open a page in your
> browser you might get a nasty message like some service is missing etc.
> That's not very helpful.
>
> I've written a simple bundle at [1] which displays the message "Apache
> Sling is starting up...". We could even enhance it with a little
> javascript to reload itself. I know we have the startup filter, but
> that's more a general purpose thing while this module is exactly there
> to improve the user experience. We could add whatever we need to improve
> that. I think we should release it and add it to launchpad to make this
> problem go away.
>
> Now the more interesting part is ... naming :)
>
> While the downloads page states "Sling Application" we always refer to
> it as "launchpad". Even the downloaded artifact has "launchpad" in it.
> Now "launchpad" has no meaning to someone new to Sling and further more
> its a technical term describing how we launch Sling. So I think we
> should not use this for our Sling downloads.
>
> "Sling Application" is far better but might not be the best description
> either. I thought about "Sling Demo Application" but that's not quiet
> right either. It's definitely not a distribution as we don't intend that
> people use this in production.
>
> So I think we should come up with a good (short) name for this thing and
> then use it throughout our documentation and in the artifact id. And
> forget about using the term launchpad. (As soon as we move to the new
> feature model we don't use launchpad technology anymore anyway).
>
> We should also improve our docs on building a real application with
> Sling. But that's a different topic and I plan to work on this in
> November to improve the docs around that.
>
> WDYT?
>
> Regards
> Carsten
>
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/demo.startup/


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to