Added more explanation of apps in intro, more specifics in applicatio…

[ekansa]

…n section

brief description of changes

This is just a start to get some feedback, but is not at all ready for merging.

issues addressed

Our conversation about Arches applications and how to explain their significance in developer guidance.

further comments

Please review and consider with @apeters 's proposed forum post. I think I'm covering some of the points, but may be garbling some of this. It would be great to provide some specifics about how to make a new Arches Application (starting from a project, right?). I read about how Django does it but the terminology seems to differ from Arches terminology a little. Anyway, those terminology issues should be an important topic for review.

---

This box must be checked

• the PR branch was originally made from the base branch

This box should be checked

• after these changes the docs build locally without error

This box should only be checked you intend to follow through on it (we can do it on our end too)

• I will cherry-pick all commits in this PR into other branches that should have them after this PR is merged

[apeters]

Suggested change

	Starting with version 7.5, Arches moved to a new architectural pattern to support certain customization needs. This new pattern called **Arches Applications** should make customizations easier to develop and maintain. This architectural pattern also aligns with standard Django practices for the introduction of reusable sets of new features.
	Starting with version 7.5, Arches adopted a new architectural pattern to support the need for implementors to easily share and maintain custom code. This new pattern, called **Arches Applications**, is similar to using "installed apps" in Django. It allows for easier development and maintenance of custom features by aligning with standard Django practices.

[apeters]

Suggested change

	The phrase **Arches Application** describes a Python package that provides some set of features added to the core (standard) Arches application. Arches application can be reused in multiple Arches projects. This terminology about *applications* and *projects* purposefully aligns with the `Django definition and use of these terms <https://docs.djangoproject.com/en/4.2/ref/applications/#projects-and-applications>`_.
	The term **Arches application** describes a Python package (usually pip installed) that provides some set of additional features beyond what core Arches provides. Arches application can be reused in multiple Arches projects.
	Applications typically include some combination of models, views, templates, static files, URLs, etc. They’re generally wired into Arches projects with the INSTALLED_APPS setting.

[apeters]

Suggested change

	Arches Arches Applications a means to power special purpose features that may not be appropriate for incorporation into the core (standard) Arches application. A given Arches App can be under version control independent of core Arches. This should make it easier to update and upgrade core Arches independently of a custom Arches Application (and vice versa).
	Arches Applications are a means to power special purpose features that may not be appropriate for incorporation into the core (standard) Arches application. A given Arches Application can be under version control independent of core Arches. This should make it easier to update, upgrade, and maintain a custom Arches Application independently of Arches core.

[apeters]

Suggested change

A given Arches Application can also be developed and shared open source. This means that the custom features powered by an Arches Application can be reused widely across the community. Because Arches Application development can proceed independently of core Arches, Arches Applications can be an excellent way for community members to experiment with features beyond those listed on the official Arches software development roadmap `official Arches software development roadmap <https://www.archesproject.org/roadmap/>`_.

Just like Arches itself, an Arches Application can also be developed, shared with the public, and be made open source. This means that the custom features powered by an Arches Application can be reused widely across the community. Because Arches Application development can proceed independently of core Arches, Arches Applications can be an excellent way for community members to experiment with features beyond those listed on the official Arches software development roadmap `official Arches software development roadmap <https://www.archesproject.org/roadmap/>`_.

[apeters]

Suggested change

Through Arches Applications, desired special features can be added to an Arches instance without forking the core (standard) Arches application code. There are many advantages to avoiding forks of the core (standard) Arches application code. By avoiding forks, one can more easily take advantage of continued upgrades and security patches applied to core Arches. This makes your use of Arches easier to maintain and secure.

Arches Applications allow you to add special features to an Arches instance without forking the core Arches code. Avoiding forks has several benefits, including easier maintenance and the ability to apply upgrades and security patches provided by core Arches.```

[apeters]

Suggested change

	Developing Arches Applications
	Developing an Arches Application

[apeters]

I think we should leave out the part about using the Django docs as a tutorial, because that's really what this is all about and there are specific differences that could be misleading

Suggested change

The **Arches Dashboard** app provides an example of how to build a custom Arches application. Experience with Django in general, and `Django app development <https://docs.djangoproject.com/en/4.2/ref/applications/#>`_ in particular, would be very useful for Arches Application development. The official Django documentation provides a great starting `tutorial for learning how to create apps <https://docs.djangoproject.com/en/4.2/intro/tutorial01/#creating-the-polls-app>`_.

The **Arches Dashboard** app provides an example of how to build a custom Arches application. Experience with Arches in general, and Arches project development in particular, would be very useful for Arches Application development.

[apeters]

Suggested change

	Customized Applications
	=======================
	While the Arches extensions architecture offers a great deal of flexibility (see below), there may be scenarios where you need additional flexibility. From a sustainability and maintenance perspective, this scenario has important risks that need to be understood and factored into long term resource planning and engineering.
	Managing long term sustainability and maintenance risks should be a core software engineering focus. As much as possible, you should ideally isolate your customized module as much as possible from the core of Arches. One way preferred way to accomplish this is to develop **Arches Applications** (see: :ref:`Creating Applications`), which are discrete Python packages that can be integrated into one or more Arches projects. The **Arches Applications** documentation details their development as well as their sustainability advantages.
	Arches Applications are a powerful way to create customizations that are isolated from the core of Arches. This isolation can help to reduce the risk of future maintenance and upgrade challenges. Arches Applications can be developed and maintained independently of the core Arches software, and can be shared with the wider Arches community. This can help to ensure that your customizations are more maintainable over time. Arches Applications can also be used to create reusable components that can be shared with members of the Arches community, which can help to reduce the overall cost of development and maintenance.

[apeters]

Suggested change

	Arches Applications
	=======================
	While the Arches extensions (see above) architecture offers a great deal of flexibility, there may be scenarios where you need additional flexibility. From a sustainability and maintenance perspective, ideally you should isolate your customized module as much as possible from the core of Arches. One way to accomplish this is to develop an **Arches Application** (see: :ref:`Creating Applications`), which are discrete Python packages that can be integrated into one or more Arches projects. The **Arches Applications** documentation details their development as well as their sustainability advantages.
	Arches Applications are a powerful way to create customizations that are isolated from the core of Arches. This isolation can help to reduce the risk of future maintenance and upgrade challenges. Arches Applications create reusable components that can be developed and maintained independently of the core Arches software, and can be shared with the wider Arches community. This can help to ensure that your customizations are more maintainable over time and can help to reduce the overall cost of development and maintenance.

[apeters]

Suggested change

	Customization of Simple Extensions
	Custom Extensions