Feydra Help

The Virtual Sandbox - How Does it Work?

Feydra allows any MVC web application to host front-end development by creating virtual sandboxes for each front-end developer. A virtual sandbox is a virtualized environment in which front-end assets (css, js, cshtml, etc.) can be selectively replaced without disturbing the back-end functionality of the web application. This virtualization allows back-end developers to create stubs for front-end functionality without having the actual front-end assets available at development time. The front-end developers can hook-up the components as they become available without impacting back-end development.

Feydra also greatly improves front-end developers’ ability to maintain and update their portion of the web application. If there are issues with the front-end functionality of the site, a front-end developer can easily update the front-end assets in their virtual sandbox and test fixes against a working web application; all without the overhead of maintaining a full Sitecore development environment or MVC application.

Ultimately, Feydra is designed to allow front-end developers to use their preferred development environment; make their changes in a virtual sandbox and test by pushing their changes to a shared location (File share, FTP, etc.) using standard tools.

How can an FED push their changes to the Virtual Sandbox?
Front-end developers need to either manually copy, choose to use an FTP or other file upload service, or use front-end tools like Sublime or WebStorm which can be configured to copy files to a target folder on each save automatically
What problem does Feydra solve?

It solves two problems:

  1. It allows Front End Developers to work independent of Back End Developers. That is, FEDs do not need to coordinate with BEDs every time they want to change front end code. They can work independently and check everything into source control to bring it all together. This also allows the front and back ends to work in parallel reducing the overall development timeline.
  2. It allows FEDs to work using their chosen design tool. That is, by separating the design process from the underlying CMS, Feydra lets FEDs design in any tool that can output the final result in CSS/JS/CSHTML (HTML).
How is working with Feydra different than what I do today?

Normally FEDs create the front end assets and Sitecore developers chop them up into components. With Feydra, SC devs can create the components as generically styled placeholders that express the data without any styling (essentially as divs). FEDs can update those on their own schedule, breaking dependencies between FEDs and BEDs and allowing for them to work in parallel.

Feydra allows Back End Devs to stub in placeholders for the front end, so the back end can architect and build the actual components based on those the IA has already designed using wireframes (or really simple ones used on every implementation). FEDs can be more efficient because they are working closer to the components, leading to less iteration. FEDs can work on the stubbed components and see how it looks in real time, without waiting for a BED to go and integrate their changes.

How do I install Feydra?
Feydra is supplied as Nuget packages. These contain the 2 DLLs and a configuration file that need to be deployed to the QA or design server (typically QA).
How is Feydra different than a headless CMS implementation?
Headless CMS strips the front end away from the content storage and production task. Content is delivered via API instead of as components or fully formed pages. Designers typically use a JavaScript framework for building pages.
How does the Activate As drop down get populated?

Activating can be done by one or more Front-end developers simultaneously - each developer can activate their own sandboxed version of the website, while being on the same physical website (which is why Feydra is so cool!). You can even activate as a different Front-end developer to see the changes.

Is there a demo video of how Fedyra works?
There sure is....please see the how to video.
How many license keys will i receive for my team?
When you purchase Feydra you are purchasing user slots.  Your organization will receive only one license key(#) for the company.  If you buy more than one user license you will use the same key for each user. 
How will FEDs merge changes in Virtual sandbox if multiple FEDs are working on the same feature?
Merging of changes only happens in source control. After a Front-end developer is happy with his/her changes inside the sandboxed virtual environment, they can have the changes committed/checked-into source control. Next, other Front-end developers can get the latest front-end code changes from source control and merge them with their own changes, after which, they can check for issues by getting copies of the changes to their own virtual sandbox environment.
Will all changes from the front-end dev share the same REPO?

All changes are shared inside source control as usual. Feydra just plays part in the testing of these changes and has nothing to do with source control

How can the FED team test their changes in a Sitecore environment?

The FED team can test after they have copied over the changes to the FeydraRoot\<User> folder, and then make the appropriate <User> active using the Feydra console (which is accessed through http://<qa_site_url>/Feydra).

By activating their user through the Feydra console, FEDs can then see changes get visualized in the environment where Feydra is installed.

How is the user list populated?

The user list gets populated by going to Feydra's control panel and adding users. Adding a user adds a folder for the user under the FeydraRoot folder inside the website's webroot, and also copies over some predefined folders to the virtual sandboxed folder for the new Front-end developer user.

How will back-end developers deploy Sitecore changes to the Feydra Virtual Sandbox?

Back-end developers do regular code and item deployments as they normally do. The back-end code can be deployed normally in the common test environment (where Feydra is also installed). This will allow front-end developers to start working on their own components - by using a virtual sandbox there - without having to set up a local (Dev) Sitecore instance.

The server doesn’t have access to the internet. Can I do the activation offline?
Unfortunately no- the server needs to be hit in a browser from a machine that can access the internet
Is there a "quick" way to get started?

Of Course!   After Feydra is installed on the server and configured properly follow the steps below!

1.      Open the control panel in your browser “/Feydra”.

2.      Select: Activate as “USER” (your user).

3.      Open the file you want to edit (CSS, JS, CSHTML) in your favorite editor.

4.      Save the file to “/FeydraRoot/USER/…” on the server (be sure to match the path).

5.      Refresh the page in the browser and see your changes.

 *Note about #4 – saving the file on the server depends on your project configuration (Unc path, remote access, FTP, etc.).This step could be automated, depending on the editor you use.

How long does it take to get a Feydra environment set up?
10 minutes, at most.
What does my team have to do to get a Feydra environment set up?
Push 2 DLLs and a configuration file to their chosen environment (usually a QA server) and create a standard file share on the server for the FED to push changes to. Virtually every team already has this environment in place already.
How does Feydra overlap with SXA?
It doesn’t, really. If you use SXA, you won’t use Feydra, since all files go into the media library where FEDs can’t access them easily. Feydra solves one of the problems SXA does (the problem of serial processes by FEDs and BEDs) in a completely different way that retains the existing development tools and processes most teams are familiar with.
Does Feydra mean the BEDs have to do a lot of work up front?

Typically, the IA team would do wireframes, then design would get involved to do the layout and component designs. Then the front end would cut them up into CSS/JS/HTML, and then the back end would start building the Sitecore componentry, leading to iteration between FE/BE as the designs and components were dialed in.

Now back end can figure out the components, data and taxonomy from the wireframes and build unstyled versions (which are vastly easier to build) from the wireframes.  FEDs can then start encoding the designs using the unstyled components that BE built.

Why do I need to buy this?
It saves time, saves effort, shortens project timeline, improves agility, and speeds iteration. In essence, we’ve broken a dependency that drives most implementation headaches.
Can I just create a reusable set of unstyled components and do the same thing as SXA? That is, avoid paying for SXA?

No, for two reasons.

  1. There are typically two kinds of components to set up: simple ones that take 5 minutes, and complex ones that are unique to the project. So a reusable set only buys you an hour or so on the first type and is not applicable to the second type.
  2. You lose the entire drag and drop page construction that frees your marketing team to pump out pages without back end help.  SXA pays for itself on that alone in about 2 months.
When should I use SXA instead of Feydra?

Feydra is good for classic Sitecore development where you are doing a full implementation – a “from scratch” implementation with lots of customization or complex design.

SXA is a great fit when there is not a ton of complexity or when there is a lot of content managed components (or both). Feydra is probably a better choice when either budget is constrained or if the componentry will be complicated.

When creating a Sitecore web application, there are many dependencies between the tasks of front-end and back-end developers. Feydra tries to break these dependencies by allowing front-end developers to work on the Sitecore web application without needing to install and maintain an entire Sitecore development environment.
Feydra needs to be deployed on the servers where the front-end developers are going to be updating front-end assets. This can be any server capable of running the web application. We recommend using a server that is not used for CI builds, since the build/deployment process will interfere with the front-end developer testing. Feydra doesn’t support load balanced servers. Load balanced servers are typically not needed in a development environment, so this should not be a major problem. The Feydra assemblies and configuration files should not be deployed to a production server.
Installation with NuGet
Feydra is distributed as a .zip of NuGet packages. These packages can be added to a local NuGet feed to make them accessible to developers and the build process. To install Feydra, simply add the NuGet package Hedgehog.Feydra to a web application and the Feydra assembly is automatically installed. If the developer is using Sitecore, add the NuGet package Hedgehog.Feydra.Sitecore to the web application. The MVC core of Feydra consists of a single assembly called Hedgehog.Feydra.dll. If this file is present in the /bin folder of a website, Feydra will be available on that server. Deleting this file will remove Feydra. The Sitecore components of Feydra consist of two additional files. These are Hedgehog.Feydra.SC.dll and Z_Feydra.config. These are installed in the /bin and /App_Config/Include folders, respectively.
Installation without NuGet

To install Feydra without using NuGet, extract the files from the NuGet packages and place the files in the folders specified in the table below:









Once Feydra is installed on a server, Feydra will verify the environment and display error messages indicating any problems found on the server that would prevent Feydra from functioning correctly. The following is a list of requirements Feydra will check at startup:

  • There is a folder called FeydraRoot in the root of the website. If the folder doesn’t exist, Feydra will try to add it. Feydra will report a problem if the folder cannot be created.
  • The Web Server needs write rights to FeydraRoot.
  • There must be a folder called /App_Data/Feydra.  If the folder doesn’t exist, Feydra will try to add it. Feydra will report an error if the folder cannot be created.
  • The Web Server needs write rights to /App_Data/Feydra and all files in that folder.
  • The Web Server needs write rights to a folder called /Areas/Feydra.
  • The property runAllManagedModulesForAllRequests must be set on the /configuration/modules element in the web.config.
Using Feydra
A front-end developer needs to be able to copy files to the web server to work with the website. There are a number of ways this can happen (Unc path, remote access, FTP, etc.). The choice of the technology for copying files to the server is left up to the end user.

The Feydra Dashboard

Feydra is controlled through the Feydra dashboard. The Feydra dashboard is accessed by the url http://[WebServer]/Feydra where [WebServer] is the domain name of the web server. The dashboard has the following functions:
  • Status – Shows the number of users, licenses and the latest log entries.
  • Users – Allows users to be added and removed. Users can also obtain a link to activate Feydra.
  • Licenses – Allows the licenses for Feydra to be updated. Viewing and adding licenses can only be performed on the local server. Remote viewing of the license screen is not permitted.
  • Settings – Allows some of the settings controlling Feydra to be updated. The initial files a user sees when their username is created can be updated here.
There is a dropdown link in the menu bar of the website that will allow a user to activate Feydra for any of the registered users.
Screenshot of Feydra dashboard

Activating Feydra

The web application behaves normally when the front-end developer has not activated Feydra. To activate Feydra, the user can open the dashboard and use the dropdown link in the menu bar to activate Feydra by selecting their username. 
Screenshot of Feydra users dropdown link
The user can also obtain an activation link from the users page by clicking on the “ ” icon in the row for the user.
Screenshot of Feydra users list

Updating the front-end assets

When the front-end developer activates Feydra, they will see a copy of the application running application. We call this the users’ virtual sandbox. This virtual sandbox uses all of the deployed front-end assets (cshtml, js, css, etc…) to run the application. If the user copies a front-end asset into their personal folder under /FeydraRoot, the front-end asset from the personal folder replaces the file of the same name and relative path in the deployed web application.
An example of this is a web application with the following folder structure:



│   └───Products

│       ├───Index.cshtml

│       └───View.cshtml



    │   └───site.css



When User1 is created, a personalized sandbox folder for that user will be created under the FeydraRoot folder:




Now, User1 can use their personal Feydra activation link to activate Feydra. The web application will look exactly as it did if Feydra isn’t activated since they have no files in their sandbox.
If the user creates a file called Index.cshtml in /FeydraRoot/User1/Area/Products, the file will override the Index.cshtml file used to render the products page on the website. This allows the front-end developer to update the front-end functionality of the web application, while allowing other parts of the application to function with existing front-end assets.
The user may also update the Site.js file in the folder /Include/js by placing a new Site.js file in /FeydraRoot/User1/Include/js. The new Site.js will be sent to the browser in place of the existing one when the page is refreshed.
If there are other users of the site who have not activated as User1, they will not see any of the changes made by User1 until the changes are deployed as part of the normal deployment process. Additional users may be created to allow multiple developers to work with the website. Each developer will only see the changes in their virtual sandbox while Feydra is activated.
If the front-end developer views the page source when Feydra is activated, they will see comments around various parts of the code indicating where the .cshtml files exist on the file system. 
Screenshot of page source with comments around various parts of the code indicating where the .cshtml files exist on the file system
This will provide hints to the front-end developer for manipulating various components on the page.

Adding Licenses

Licenses are added to Feydra using the license management screen. This screen may only be accessed when logged into the console of the local server. 
Screenshot of Feydra license management screen
Feydra will not allow users to activate their virtual sandbox if there aren’t enough CAL’s for all of the created users.
The user can add new license keys by selecting Add License.
The “” (Refresh) action will contact the Hedgehog License Server and update the number of CAL’s (Client Access License) or license type if it has changed.
The “” (Delete) action will remove a license and its associated CAL’s from the server.

Feydra Settings

The Feydra settings screen allows the developer to view and/or change the settings Feydra uses on the server. 
Screenshot of Feydra settings screen
To use this screen, simply make the changes needed to the settings and click “Update Settings”
The settings the user can update are as follows:
  • Cookie Name – The name of the cookie Feydra uses to maintain the current user activation.
  • Root Folder – The name of the Feydra root folder. If this is changed after users are created, the developer is responsible for moving the users files into the new location.
  • User Create Actions – This allows the developer to specify files to copy (relative to the web root) into each virtual sandbox when the user is created. This is useful for setting up files like the /Views/web.config, since these files are needed by MVC to build the views correctly.
Feydra supports multiple user sandboxes, allowing multiple front-end developers to work with a single web application. This will dramatically reduce the costs of maintaining development and test environments for front-end developers while allowing them to complete their task more efficiently.

Need support on Feydra?
Still have questions or concerns?
We've got you covered. Our support team is top notch, and their quick response time is legendary. Contact Support at any time and about any issue.