Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
D
Developer Documentation
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
brienne
Developer Documentation
Commits
46b91868
Commit
46b91868
authored
7 years ago
by
totten
Browse files
Options
Downloads
Patches
Plain Diff
AngularJS Overview - Misc update
parent
5cb11b87
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/framework/angular.md
+28
-26
28 additions, 26 deletions
docs/framework/angular.md
with
28 additions
and
26 deletions
docs/framework/angular.md
+
28
−
26
View file @
46b91868
...
...
@@ -26,19 +26,19 @@ and code.
The CiviCRM-AngularJS integration must balance the expectations of these
two cultures. The balance works as follows:
*
__
JS+HTML__: The general structure of the Javascript and HTML fi
les
should meet
the frontend developers' expectations. These files should b
e
grounded in the same notations and concepts as the upstream AngularJS
framework. (This means that AngularJS is not abstracted, wrapped, or
mapped by an intermediary like HTML_QuickForm, Symfony Forms or Drupal
Form API.)
*
__Build__: The process of building or activating modules should meet
administrators' expectations
. Th
ey should be managed by the PHP
application. (This means that you won't see
`gulp`
or
`grunt`
managing
the final build -- because PHP logic fills that role
.)
*
__
Web Services
__: The general structure of
web-services should meet
the backend developers' expectations. These are
implemented in PHP
(typically with CiviCRM APIv3).
*
__
Build/Activation__: The process of building or activating modu
les
should meet
administrators' expectations. It should be managed by th
e
PHP application. (This means that you won't see
`gulp`
or
`grunt`
orchestrating the final build -- because PHP logic fills that role.)
*
__Frontend Code uses Angular (JS+HTML)__: The general structure of the
Javascript and HTML files should meet the frontend developers'
expectations. These files should be grounded in the same notations and
concepts as the upstream AngularJS framework
.
(
Th
is means that AngularJS
is not abstracted, wrapped, or mapped by an intermediary like
HTML_QuickForm, Symfony Forms or Drupal Form API
.)
*
__
Backend Code uses Civi API (PHP)
__: The general structure of
web-services should meet
the backend developers' expectations.
These are
implemented in PHP
(typically with CiviCRM APIv3).
## Basics
...
...
@@ -50,25 +50,27 @@ page -- it's an HTML document that looks a lot like this:
<!-- URL: https://example.org/civicrm/a -->
1:
<html>
2:
<head>
3:
<script
type=
"text/javascript"
src=
"**all the Javascript files**"
></script>
4:
<link
rel=
"stylesheet"
href=
"**all the CSS files**"
/>
5:
</head>
6:
<body>
7:
<div>
...site wide header...
</div>
8:
<div
ng-app=
"crmApp"
></div>
9:
<div>
...site wide footer...
</div>
10:
</body>
11:
</html>
3:
<link
rel=
"stylesheet"
href=
"**all the CSS files**"
/>
4:
<script
type=
"text/javascript"
src=
"**all the Javascript files**"
></script>
5:
<script
type=
"text/javascript"
>
var
CRM
=
{
**
prefetched
settings
/
data
**
};
</script>
6:
</head>
7:
<body>
8:
<div>
...site wide header...
</div>
9:
<div
ng-app=
"crmApp"
></div>
10:
<div>
...site wide footer...
</div>
11:
</body>
12:
</html>
```
The first interaction comes when CiviCRM generates the initial HTML page:
*
CiviCRM listens for requests to the path
`civicrm/a`
. (It does this in a
way which is compatible with multiple CMSs -- Drupal, Joomla, WordPress, etc.)
*
CiviCRM builds the list of JS/CSS files in lines 3-4. (It does this in a
way which allows extensions to add new JS/CSS files.)
*
CiviCRM builds the list of CSS/JS/JSON resources in lines 3-5. (It does this in a
way which allows extensions to add new CSS/JS/JSON. See also:
[
Resource Reference
](
https://wiki.civicrm.org/confluence/display/CRMDOC/Resource+Reference
)
.)
*
CiviCRM ensures that the page includes the site-wide elements, such as
lines
7
and
9
. (It does this in a way which is compatible with multiple CMSs.)
lines
8
and
10
. (It does this in a way which is compatible with multiple CMSs.)
Once the page is loaded, it works just like any AngularJS 1.x application.
It uses concepts like
`ng-app`
, "module", "directive", "service", "component", and
...
...
@@ -95,5 +97,5 @@ the discussion if you have a beginner-level understanding of both.
*
[
Quick Start
](
angular/quickstart.md
)
: How to create a new screen in the CiviCRM-Angular UI
*
[
File Names
](
angular/files.md
)
: How AngularJS files are named in
`civicrm-core`
and
`civix`
*
[
Loader
](
angular/loader.md
)
: How
JS/CSS files are loaded
*
[
Loader
](
angular/loader.md
)
: How
to find and load JS/CSS files for CiviCRM-Angular
*
[
Modifications
](
angular/modify.md
)
: How a third-party can modify the content of a CiviCRM-Angular UI
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment