Thanks again Sander,
You always come thru with great answers :)
But lost on "
So, you want to build an universal editor, that can CRUD each of those
models. Did I get that right? You don't need those models to interact in
your views. For starters, you just want a CRUD for each and every separate
model?
Authentication and validation is enforced by the server right?"
My CRUDservice is minimal, just has:
index : function(url) {
return $http.get(urls.BASE_API + url);
},
get : function(url) {
return $http.get(urls.BASE_API + url);
},
// save a model (pass in model formData)
save : function(url, formData) {
return $http({
method: 'POST',
url: urls.BASE_API + url,
headers: { 'Content-Type' :
'application/x-www-form-urlencoded' },
data: $.param(formData)
});
},
// update a model
update : function(url, formData) {
return $http({
method: 'PUT',
url: urls.BASE_API + url,
headers: { 'Content-Type' :
'application/x-www-form-urlencoded' },
data: $.param(formData)
});
},
// destroy a model
destroy : function(url) {
return $http.delete(urls.BASE_API + url);
}
I do not know what I want to build :)
What I want to do is build it right basically.
There are / will be 15 - 20 one off type functions outside the realm of
typical CRUD functionality, I will deal with that later. But right now its
rather basic, Apples/edit/[id] show the form save and i redirect back to
apples/ good stuff see the edited record. it will be live editable
eventually but for now the site functions like a regular html / non ajaxed
style site. I want to lay the ground work correct before moving onto more
advanced functionality to that aspect. I do have a few forms that are live
edit on change so no real index, such as user/settings which is a fancy
slide / toggle users select the settings for the site and when changed auto
saves via the PUT request. I am trying to avoid front-end validation at
this point, rather the server do it in real time and provide feedback vs
front-end validation rules and repeated in backend rules, try to avoid
repeating that.
My app though rather large in scale database is 90+ tables but the back-end
handles all the trivial stuff, front end will be simply "cosmetic" and
simply using naming conventions able to use url's as a way to communicate
with the back end and the back-end is configured in reverse to accept the
pointers from request. so requests made to the API use $state as a
reference and back-end is configured to recognize the url as POST, GET ,
PUT, DELETE, PATCH, what not and act according.... I am sure most people do
the same thing
I was thinking I will eventually add in the "live" validation Angular can
perform so I will in fact need to expand into a form handler specific to
forms as you noted.
I will look at your links as they always provide great insight :)
On Saturday, September 26, 2015 at 3:05:43 AM UTC-2:30, Dave Abbott wrote:
>
> I am new at Angular...admitted. Thanks to all so far who have helped along
> the way!
>
> But still lost so maybe I am over / under thinking things.
> So basically I have a back-end API in Laravel 5, and all Angualr request
> hit some end-point for requests as expected.
> Back-end has 60+ controllers / 70+ models and enter Angular :)
>
> I am looking at it as a CRUD front-end interface to get data and save
> data....rather basic nothing fancy to this point.
>
> I was pointed to John Papas guide to Angular code structure and I know its
> a style guide, not a tutorial on the building the app, rather how to code
> it but I was struck by his references to getAverngers() or getAvernger()
> and I think why getAvengers()? next week I add StarWars do I re-write the
> exact same functionality to call getStarWars() getStarTrek?
>
> To me I look at it like getRecord($fromWhereUrl, $id-I-Want) to get 1
> record a or getRecords($url = API + '/starwars') to get all records. To me
> that seems easier. Avengers, StarWars, Apples or Oranges they mean nothing
> other than a record in a database. To me it seems easier to pass a url and
> variable for id to get what you need from a few different functions.....no?
>
> Delete a record why have deleteCharacter(id); and somewhere else have
> deleteApple(id) or over and over performing the same thing? Why is just not
> easier to pass a url where you want to hit on the API?
>
> I do not want to create 60+ angualr controllers / services / directives
> that just do the same thing with just different function names.
>
> What am I missing here?
>
> I know every app has different functionality and such but with 5 or 6 core
> functions could you not handle most of the heavy lifting?
>
> getRecord($url, $id) to pull 1 single record from some where
>
> getRecords($url) to pull multiple records some where
>
> putRecord($url, $id) to update a record some where
>
> postRecord($url) to save a new records some where
>
> deleteRecord($url, $id)
>
> The backed auth should handle the permissions of who can do what the front
> end should not care? I am using JWT authentication so no matter what the
> front end orders the back determines if your going to get what you ordered.
>
> Most UI / UX "should" follow a similar pattern in response so save /
> update / delete / fail alerts / exceptions / redirects what not so if each
> function did the same you have a universal look and feel tweak one and its
> a global look your not going thru replacing the functionality all over the
> app.
>
> As I said, new so not trying to be rude, just trying to understand.
>
> I wish there was a real world app, scenario tutorial guide that showed
> multiple controllers, services, directives. Not the typical single app.js
> script all put into 1 file. Something simple like Users, Comments, Posts
> where a new person could see how to work with multiple Angular files and
> how they interact with a back-end.
>
> Thanks again to all :)
>
> Dave
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
