Hi all,
below my comments followings Hans email
Il 21/01/2021 20:50, Hans Van Akelyen ha scritto:
Hi All,
I would go for option 3, a default project that is already pre-configured
and can't be deleted (from inside the gui). I do not like obscure folders
in my home folder so I would store the information next to the ./config.
What we all agree on is that the UI around the projects might need to be
changed a bit. I do not like the pop-ups when creating a new project, a
wizard with a couple of "next next next" steps with some more information
and links to the documentation might be a better way to create a project.
I'm fine too on option 3 proposed by Matt but I don't understan what
Hans is saying when he says that "the default project can't be deleted"
I do agree with Sergio that the ability to open/remove projects from the
list and menu items to do this are in place. On the other hand I do not
agree with the need of creating a default environment. The environments are
great but only serve a purpose in multi-environment or bigger projects. We
have documentation about our layered parameter/environments set-up but
these are unfortunately already outdated.
I agree that environments are targeted to big projects but in my opinion
environments are the place where project's variables, generally
speaking, must reside. So a default environment can be always created by
default only for this purpose even if hidden from user's eyes (if we
want to keep things simpler). I'm convinced that a similar approach
gives a cleaner architectural design by rationalizing the way project's
variables are managed.
On the other side, it is unclear to me how to close a project to
open/create another one. This is another feature that is needed in my
opinion.
To counter Sergio on one another point, you can edit the environment
variables via the UI the only thing you can't and might be an extra nice
feature is to create a new empty environment configuration file. you have
to create an empty json file containing {} to allow the edit button to work
we still hold true to our "everything should be possible via the GUI" way
of working.
Tried and it works thanks thanks for pointing me there. I've not found
any reference in available documentation but it could be that I've
missed something.
Cheers
Sergio
Cheers,
Hans
On Thu, Jan 21, 2021 at 8:00 PM Bart Maertens <[email protected]> wrote:
Hi Matt, Hop,
Option 3 seems to be the most transparent and intuitive approach if
people choose not to configure projects.
I guess one of the main reasons why new users wouldn't want to work in
projects is because they fear the unknown, projects have a sense of
complexity or they feel out of their comfort zone one way or another.
I guess the need for a project structure will automatically come when a
user gets more comfortable in Hop Gui, begins to do more
complex work, starts to work on different (real life) projects etc.
One approach to keep projects close by in the user interface could be to
show the project toolbar as disabled or greyed out, so it's right there to
enable.
We already have ctrl-click to enable/disable hops, we could consider making
ctrl-click a default combination to enable disable functionality. That
functionality would be the project toolbar in this case, but could also
work for metadata objects that are not required in a given project etc.
Regards,
Bart
On Thu, Jan 21, 2021 at 4:18 PM Matt Casters <[email protected]
.invalid>
wrote:
Dear Hoppers,
In a lot of other IDE like tools you find a project-centric approach to
developing something.
Using a project is mostly enforced by the way that software works, for
example Eclipse or Idea.
In Hop we implemented projects as part of a plugin because sometimes you
just want to trim things down to the bare essentials. So essentially
what
this comes down to is that you can use projects and put all your work
under
a certain folder as per usual OR you can do your own thing and configure
Hop just the way you like.
Right now though it's not possible to not use a project once you've used
one in the GUI.
Brandon raised this issue in a JIRA case and on the chat and perhaps it
was
a misunderstanding but in any case we are faced with some options to
reduce
confusion:
1. Force the use of a project on a user. Don't even allow new files or
metadata to be created without a project to work in. This is how most
tools work but the downside is that we'd have to nag the user for the
creation of a new project before anything can be done.
2. Keep things as the way they are but allow the user to disconnect from
a
project. Carify where metadata is stored in this scenario. We could
simply
add a new button in the toolbar to "disconnect" from a project which
would
simply clear the project combo box.
3. Option 1. but with automatic creation of a "Default" project. We can
store that project somewhere in a standard location (configurable) like
Eclipse does in ~/workspace/ or simply in the config folder next to the
metadata (./config/projects/default)
I honestly have no opinion on it so I thought I'd ask. It's not urgent
but
it warrants clarification since this confusion will continue to bubble
up I
think. Maybe you have another idea? Let us know. I'd be happy to make
the changes to the codebase, those are likely quite limited.
I also think this issue can be tied together with the shipment of
standard
samples packages with the Hop distribution. Perhaps if we have a Default
project we could also have a "Samples" project.
Cheers,
Matt
--
Best Regards/Distinti Saluti
Sergio Ramazzina
Senior Solution Architect
Via Milano 78
20013 Magenta (MI) - ITALY
mobile : +39 347 2103689
Tel: +39 02 87158700
Fax: +39 02 87151947
website: http://www.serasoft.it <http://www.serasoft.it> - email :
[email protected] <mailto:[email protected]>
skype : sramazzina - Follow me on twitter: sramazzina
View my profile on LinkedIn: http://www.linkedin.com/in/sramazzina
<http://www.linkedin.com/in/sramazzina>
