Unicorn Client Extensions about unicorn

[kamsar]

Sounds like a good PR. So far unicorn doesn't have any dependency on
installing a package/sitecore items (easy to install/remove).

Sitecore nuget allows installing items with an active rocks connection but
it's not particularly resilient (eg install without a connection succeeds
without error). Been throwing around the idea of a self bootstrapping
install - maybe an initialize processor that deserializes embedded
resources or something. Thoughts?
On Tue, Mar 3, 2015 at 3:54 PM Reto Hugi [email protected] wrote:

Hi Kam

We're writing some Sitecore Content Editor Helpers for Unicorn right now.

• a gutter icon, indicating if the item is serialized according to the
  Serialization.config or not (not based on file system serialization, so it
  can help content Authors as well).
• an item validator that can "block" saving items, that are within the
  serialization pattern. Again, this can protect admins on production editing
  items they shouldn't.

Now, would you be comfortable if we would add these client extensions to
the Unicorn project (through PR) - it will ship with serialized items,
additional icons and configs and thus we would need to extend the file
structure and nuspec of the project. Or should we create a new "Unicorn
Extension" repo/project, hosted elsewhere for that?

Thanks for your feedback,

• reto

—
Reply to this email directly or view it on GitHub
#36.

[pveller]

I can tell you what we're doing in SCORE. It's also distributed as a NuGet and it also deploys Sitecore items automatically. The NuGet comes with a very simple package deployment service (asmx) that I drop into your Sitecore and then call into it with the .update package that is also packed into the NuGet. Very similar to what TDS is doing when they create a _DEV in your instance. In SCORE we're using TDS (and advocating its use among our clients, sorry! :) so the NuGet inspects the *.TDS.Master for the URL and the file system path. You can make it interactive and ask for those details from the console or use active Rocks connection. You won't use it (the Rocks connection) to delivery the items, you will use your own service. And all the service needs to do is call into the Sitecore.Update like Ship does, for example. Not perfect. Just another idea.

[retohugi]

Thanks, Kam

We're actually using the Sitecore Rocks way of installing items. And yes, the solution needs improvements and it is a bit against the workflow of installing other nuget packages.

Of course I'm open to how we should include the serialized files. But because I lack of clever alternatives out of the box, I'd include a Rocks-like installation to the package.

One more thing:
To make the setup a bit cleaner we usually create a *.Core package and a Website package (i.e. Unicorn.Core & Unicorn) where Unicorn has a dependency on Unicorn.Core. The core package contains just DLL(s) and the other is a VS Website Project providing the structure of the Sitecore web root. For example it has /App_Config/Include/Serialization.config and there would be a place for the icons in /sitecore/shell/Themes/Standard/Unicorn.zip
It helps if somebody wants to extend on Unicorn because they can just reference Unicorn.Core in their project without messing with content being installed to their code library project.

Proposed Structure:

<repo-root>
  [...]
   -- serialization
   -- src\
     `-- \Unicorn\ <-- this is the root of the Unicorn.Core project
     `-- \Unicorn.Website\ <-- this is the root of the Unicorn project
          `--\<configs and content come here>

This will also require a change in the nuspec files.

Now, writing all this down I am not sure anymore if it really is worth it. We can use unicorn as a dev dependency and simply provide the extensions in a separate repo.

Feedback Welcome :)

[kamsar]

Your design sounds fine, and mirrors what most of my other projects use. Up
to you, if you prefer a secondary repository.
On Wed, Mar 4, 2015 at 1:08 AM Reto Hugi [email protected] wrote:

Thanks, Kam

We're actually using the Sitecore Rocks way of installing items. And yes,
the solution needs improvements and it is a bit against the workflow of
installing other nuget packages.

Of course I'm open to how we should include the serialized files. But
because I lack of clever alternatives out of the box, I'd include a
Rocks-like installation to the package.

One more thing:
To make the setup a bit cleaner we usually create a .Core package and a
*Website package (i.e. Unicorn.Core & Unicorn) where Unicorn has a
dependency on Unicorn.Core. The core package contains just DLL(s) and the
other is a VS Website Project providing the structure of the Sitecore web
root. For example it has /App_Config/Include/Serialization.config and
there would be a place for the icons in
/sitecore/shell/Themes/Standard/Unicorn.zip
It helps if somebody wants to extend on Unicorn because they can just
reference Unicorn.Core in their project without messing with content
being installed to their code library project.

Proposed Structure:

[...] -- serialization -- src\ `-- \Unicorn\ <-- this is the root of the Unicorn.Core project `-- \Unicorn.Website\ <-- this is the root of the Unicorn project `--

This will also require a change in the nuspec files.

Now, writing all this down I am not sure anymore if it really is worth it.
We can use unicorn as a dev dependency and simply provide the extensions in
a separate repo.

Feedback Welcome :)

—
Reply to this email directly or view it on GitHub
#36 (comment).

[retohugi]

Thanks for your feedback. We'll finish the work and get back to you, when it is done. :)

[kamsar]

The Unicorn.Core NuGet package has been implemented in 85382a9, and will be part of the next release.

[kamsar]

@retohugi if you're working on these extensions still note that the guts will see a pretty major overhaul in the next version. The same concepts will still be present, but getting to them may be different.

At the moment development is in the giblets branch (don't ask...), and in the parallel Gibson project (which may be renamed before release). It's all very alpha at the moment but it'll end up being quite nice. New serialization format for easy merging, better pathing, etc.

Of note, at launch I am NOT planning to support the legacy serialization format (Sitecore's) or the Sitecore-style folder pathing structure. It may be possible to do so, but as I don't plan to use them any longer I have other things to spend time on ;)

[retohugi]

Hi Kam

Sorry for the very late reply. The client extensions are actually finished. I just did not have the time to have a look at giblets. I guess that's where we start integrating them, right?
As soon as I have some spare time, i'll work on a PR for you. Let me know if things change significiantly or in case I'm already to late to the party. Again, sorry for the late feedback.

reto

[kamsar]

No problem. I'm not sure what you ended up with, but U3 core has:

• A content editor warning when an item is under Unicorn control
• A "prod mode" where saving anything under Unicorn results in a yes/no confirmation dialog
• If an item, or tree, is under Unicorn the default developer tab serialize controls turn into Unicorn, enabling partial syncs and reserializes

[retohugi]

Basically the first two in the list plus gutter icons is what we have and it was written for Unicorrn 2. I'll have a look at U3 and see what makes sense...

[kamsar]

@retohugi if you ever get around to this just open a PR. I'ma close this issue for the moment :)