2:39 a.m.
See thread "Shared messages between themes". I propose to remove built-in
themes from themes directory and rather load from a module/jar.
Reasoning behind this is two fold:
a) Support theme resources for sharing messages between themes
b) Built-in themes should not be modified
Within themes we'd update the README.txt file to provide the location of
the built-in themes so users can crack open the jar (zip) to view the
built-in themes for reference when they are creating their own custom
themes.
7:15 a.m.
-1
I think this would be bad from a developer's usability perspective. We
should not make it harder for the developer to see what he is extending.
Also, a developer who is new to Keycloak can make small changes to the
built-in theme and see the effects right away. This is important for
the "out-of-the-box" experience where a developer is trying to decide
whether or not to use Keycloak.
We shouldn't make it harder to start hacking on themes. We just warn
them that the proper way to do it in production is to extend the theme.
It's just like what we did with WildFly and the "toy" database that
comes with it. We want developers to be able to get started a quickly
as possible, while noting that this is not suitable for production.
On 9/19/2019 3:39 AM, Stian Thorgersen wrote:
See thread "Shared messages between themes". I propose to
remove built-in
themes from themes directory and rather load from a module/jar.
Reasoning behind this is two fold:
a) Support theme resources for sharing messages between themes
b) Built-in themes should not be modified
Within themes we'd update the README.txt file to provide the location of
the built-in themes so users can crack open the jar (zip) to view the
built-in themes for reference when they are creating their own custom
themes.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:58 a.m.
Is it really that much of an inconvenience to unzip a file?
# cd themes
# unzip ../themes.zip .
On Thu, 19 Sep 2019, 14:23 Stan Silvert, <ssilvert(a)redhat.com> wrote:
-1
I think this would be bad from a developer's usability perspective. We
should not make it harder for the developer to see what he is extending.
Also, a developer who is new to Keycloak can make small changes to the
built-in theme and see the effects right away. This is important for
the "out-of-the-box" experience where a developer is trying to decide
whether or not to use Keycloak.
We shouldn't make it harder to start hacking on themes. We just warn
them that the proper way to do it in production is to extend the theme.
It's just like what we did with WildFly and the "toy" database that
comes with it. We want developers to be able to get started a quickly
as possible, while noting that this is not suitable for production.
On 9/19/2019 3:39 AM, Stian Thorgersen wrote:
> See thread "Shared messages between themes". I propose to remove built-in
> themes from themes directory and rather load from a module/jar.
>
> Reasoning behind this is two fold:
>
> a) Support theme resources for sharing messages between themes
> b) Built-in themes should not be modified
>
> Within themes we'd update the README.txt file to provide the location of
> the built-in themes so users can crack open the jar (zip) to view the
> built-in themes for reference when they are creating their own custom
> themes.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:59 a.m.
By the way this would make upgrading simpler as themes dir can just be
left. Now folks have to pick what to copy being careful not to copy built-in
On Thu, 19 Sep 2019, 14:58 Stian Thorgersen, <sthorger(a)redhat.com> wrote:
Is it really that much of an inconvenience to unzip a file?
# cd themes
# unzip ../themes.zip .
On Thu, 19 Sep 2019, 14:23 Stan Silvert, <ssilvert(a)redhat.com> wrote:
> -1
>
> I think this would be bad from a developer's usability perspective. We
> should not make it harder for the developer to see what he is extending.
>
> Also, a developer who is new to Keycloak can make small changes to the
> built-in theme and see the effects right away. This is important for
> the "out-of-the-box" experience where a developer is trying to decide
> whether or not to use Keycloak.
>
> We shouldn't make it harder to start hacking on themes. We just warn
> them that the proper way to do it in production is to extend the theme.
>
> It's just like what we did with WildFly and the "toy" database that
> comes with it. We want developers to be able to get started a quickly
> as possible, while noting that this is not suitable for production.
>
> On 9/19/2019 3:39 AM, Stian Thorgersen wrote:
> > See thread "Shared messages between themes". I propose to remove
> built-in
> > themes from themes directory and rather load from a module/jar.
> >
> > Reasoning behind this is two fold:
> >
> > a) Support theme resources for sharing messages between themes
> > b) Built-in themes should not be modified
> >
> > Within themes we'd update the README.txt file to provide the location of
> > the built-in themes so users can crack open the jar (zip) to view the
> > built-in themes for reference when they are creating their own custom
> > themes.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:22 a.m.
I'd totally support moving the built-in themes to an archive.
But it has to be documented very well, which steps to perform and how to extend the
built-in's. And perhaps a README file in the themes folder pointing to the
documentation would also help.
- Niko
Stian Thorgersen <sthorger(a)redhat.com> hat am 19. September
2019 um 14:59 geschrieben:
By the way this would make upgrading simpler as themes dir can just be
left. Now folks have to pick what to copy being careful not to copy built-in
On Thu, 19 Sep 2019, 14:58 Stian Thorgersen, <sthorger(a)redhat.com> wrote:
> Is it really that much of an inconvenience to unzip a file?
>
> # cd themes
> # unzip ../themes.zip .
>
>
>
> On Thu, 19 Sep 2019, 14:23 Stan Silvert, <ssilvert(a)redhat.com> wrote:
>
>> -1
>>
>> I think this would be bad from a developer's usability perspective. We
>> should not make it harder for the developer to see what he is extending.
>>
>> Also, a developer who is new to Keycloak can make small changes to the
>> built-in theme and see the effects right away. This is important for
>> the "out-of-the-box" experience where a developer is trying to decide
>> whether or not to use Keycloak.
>>
>> We shouldn't make it harder to start hacking on themes. We just warn
>> them that the proper way to do it in production is to extend the theme.
>>
>> It's just like what we did with WildFly and the "toy" database
that
>> comes with it. We want developers to be able to get started a quickly
>> as possible, while noting that this is not suitable for production.
>>
>> On 9/19/2019 3:39 AM, Stian Thorgersen wrote:
>> > See thread "Shared messages between themes". I propose to remove
>> built-in
>> > themes from themes directory and rather load from a module/jar.
>> >
>> > Reasoning behind this is two fold:
>> >
>> > a) Support theme resources for sharing messages between themes
>> > b) Built-in themes should not be modified
>> >
>> > Within themes we'd update the README.txt file to provide the location
of
>> > the built-in themes so users can crack open the jar (zip) to view the
>> > built-in themes for reference when they are creating their own custom
>> > themes.
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:58 a.m.
On 9/19/2019 8:58 AM, Stian Thorgersen wrote:
Is it really that much of an inconvenience to unzip a file?
# cd themes
# unzip ../themes.zip .
Yes. Any inconvenience is bad. You don't want to do
any extra steps
that hinders a new developer from doing something that makes him smile.
The easier it is to get that first "success" the greater the chance he
will continue onward and choose Keycloak.
On Thu, 19 Sep 2019, 14:23 Stan Silvert, <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
-1
I think this would be bad from a developer's usability
perspective. We
should not make it harder for the developer to see what he is
extending.
Also, a developer who is new to Keycloak can make small changes to
the
built-in theme and see the effects right away. This is important for
the "out-of-the-box" experience where a developer is trying to decide
whether or not to use Keycloak.
We shouldn't make it harder to start hacking on themes. We just warn
them that the proper way to do it in production is to extend the
theme.
It's just like what we did with WildFly and the "toy" database that
comes with it. We want developers to be able to get started a
quickly
as possible, while noting that this is not suitable for production.
On 9/19/2019 3:39 AM, Stian Thorgersen wrote:
> See thread "Shared messages between themes". I propose to remove
built-in
> themes from themes directory and rather load from a module/jar.
>
> Reasoning behind this is two fold:
>
> a) Support theme resources for sharing messages between themes
> b) Built-in themes should not be modified
>
> Within themes we'd update the README.txt file to provide the
location of
> the built-in themes so users can crack open the jar (zip) to
view the
> built-in themes for reference when they are creating their own
custom
> themes.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1 p.m.
On Thu, Sep 19, 2019 at 7:14 PM Stan Silvert <ssilvert(a)redhat.com> wrote:
The easier it is to get that first "success" the greater
the chance he
will continue onward and choose Keycloak.
Being new to KeyCloak - this is something
I can agree with. The glee
of running a project that just works the first time is amazing.
It's part of the reason we stuck with KeyCloak, if I'd have to guess.
2:52 a.m.
Making things easy and just working is a high priority to us, but I wonder
if it would actually be easier and more guaranteed to just work if built-in
themes is in a zip. Arguments are basically:
* Prevents anyone modifying the built-in themes, which if you do would
bring you problems later on
* Makes it easier to update as the whole themes directory can be kept.
Currently the built-in themes has to be replaced, but not custom themes
What might actually be real nice is to have a little tool to work with
themes. Something like
kc-theme create --theme mytheme --parent keycloak
kc-theme list-templates --type login
kc-theme add-custom-template --theme mytheme --template login.ftl
kc-theme add-custom-messages --theme mytheme --language en
On Thu, 19 Sep 2019 at 20:00, Asbjørn Thegler <asbjoern(a)deranged.dk> wrote:
On Thu, Sep 19, 2019 at 7:14 PM Stan Silvert
<ssilvert(a)redhat.com> wrote:
> The easier it is to get that first "success" the greater the chance he
> will continue onward and choose Keycloak.
Being new to KeyCloak - this is something I can agree with. The glee
of running a project that just works the first time is amazing.
It's part of the reason we stuck with KeyCloak, if I'd have to guess.
6:36 a.m.
How about having both?
Out of the box, it's in development mode and it uses what we have
today. But we show warnings everywhere that you are in development mode.
In production mode, it always uses the zip.
On 9/20/2019 3:52 AM, Stian Thorgersen wrote:
Making things easy and just working is a high priority to us, but I
wonder if it would actually be easier and more guaranteed to just work
if built-in themes is in a zip. Arguments are basically:
* Prevents anyone modifying the built-in themes, which if you do would
bring you problems later on
* Makes it easier to update as the whole themes directory can be kept.
Currently the built-in themes has to be replaced, but not custom themes
What might actually be real nice is to have a little tool to work with
themes. Something like
kc-theme create --theme mytheme --parent keycloak
kc-theme list-templates --type login
kc-theme add-custom-template --theme mytheme --template login.ftl
kc-theme add-custom-messages --theme mytheme --language en
On Thu, 19 Sep 2019 at 20:00, Asbjørn Thegler <asbjoern(a)deranged.dk
<mailto:asbjoern@deranged.dk>> wrote:
On Thu, Sep 19, 2019 at 7:14 PM Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
> The easier it is to get that first "success" the greater the
chance he
> will continue onward and choose Keycloak.
Being new to KeyCloak - this is something I can agree with. The glee
of running a project that just works the first time is amazing.
It's part of the reason we stuck with KeyCloak, if I'd have to guess.
8:04 a.m.
That's just messy
On Fri, 20 Sep 2019 at 13:36, Stan Silvert <ssilvert(a)redhat.com> wrote:
How about having both?
Out of the box, it's in development mode and it uses what we have today.
But we show warnings everywhere that you are in development mode.
In production mode, it always uses the zip.
On 9/20/2019 3:52 AM, Stian Thorgersen wrote:
Making things easy and just working is a high priority to us, but I wonder
if it would actually be easier and more guaranteed to just work if built-in
themes is in a zip. Arguments are basically:
* Prevents anyone modifying the built-in themes, which if you do would
bring you problems later on
* Makes it easier to update as the whole themes directory can be kept.
Currently the built-in themes has to be replaced, but not custom themes
What might actually be real nice is to have a little tool to work with
themes. Something like
kc-theme create --theme mytheme --parent keycloak
kc-theme list-templates --type login
kc-theme add-custom-template --theme mytheme --template login.ftl
kc-theme add-custom-messages --theme mytheme --language en
On Thu, 19 Sep 2019 at 20:00, Asbjørn Thegler <asbjoern(a)deranged.dk>
wrote:
> On Thu, Sep 19, 2019 at 7:14 PM Stan Silvert <ssilvert(a)redhat.com> wrote:
> > The easier it is to get that first "success" the greater the chance
he
> > will continue onward and choose Keycloak.
> Being new to KeyCloak - this is something I can agree with. The glee
> of running a project that just works the first time is amazing.
>
> It's part of the reason we stuck with KeyCloak, if I'd have to guess.
>
10:32 a.m.
On 9/20/2019 9:04 AM, Stian Thorgersen wrote:
That's just messy
It solves everyone's concerns and
it's easy to implement.
It would be kind of nice to have a development mode for other things as
well. We already have it for the new account console.
It would also be great to have tooling like you suggest. But we've
always rejected that as something that could easily turn into a huge
project.
On Fri, 20 Sep 2019 at 13:36, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
How about having both?
Out of the box, it's in development mode and it uses what we have
today. But we show warnings everywhere that you are in
development mode.
In production mode, it always uses the zip.
On 9/20/2019 3:52 AM, Stian Thorgersen wrote:
> Making things easy and just working is a high priority to us, but
> I wonder if it would actually be easier and more guaranteed to
> just work if built-in themes is in a zip. Arguments are basically:
>
> * Prevents anyone modifying the built-in themes, which if you do
> would bring you problems later on
> * Makes it easier to update as the whole themes directory can be
> kept. Currently the built-in themes has to be replaced, but not
> custom themes
>
> What might actually be real nice is to have a little tool to work
> with themes. Something like
>
> kc-theme create --theme mytheme --parent keycloak
> kc-theme list-templates --type login
> kc-theme add-custom-template --theme mytheme --template login.ftl
> kc-theme add-custom-messages --theme mytheme --language en
>
> On Thu, 19 Sep 2019 at 20:00, Asbjørn Thegler
> <asbjoern(a)deranged.dk <mailto:asbjoern@deranged.dk>> wrote:
>
> On Thu, Sep 19, 2019 at 7:14 PM Stan Silvert
> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
> > The easier it is to get that first "success" the greater
> the chance he
> > will continue onward and choose Keycloak.
> Being new to KeyCloak - this is something I can agree with.
> The glee
> of running a project that just works the first time is amazing.
>
> It's part of the reason we stuck with KeyCloak, if I'd have
> to guess.
>
1924
days inactive
1925
days old
10 comments
4 participants
participants (4)
-
Asbjørn Thegler -
Niko Köbler -
Stan Silvert -
Stian Thorgersen