Turkiyenin en sevilen filmlerinin yer aldigi porno internet sitemiz olan ve sex tarzi bir site olan sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir.
Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.
Hi. I am new to ExtJs, and I need help with an issue relating to
overall application design and architecture. I am sorry that this post will be
rather long, but I need to explain what I am trying to achieve, in order to
hope that I can get meaningful answers. It may also serve as the staring
point of an interesting discussion. If all I am saying here is commonplace to
you experts, please allow for the fact that I only came across ExtJS a couple
of days ago also, pls note that English is not my mother tongue.
I am designing a pure AJAX largish (30-50 "pages") application,
which I would like to function in the following way:
I want to have a single html page, which acts as the "container" for the
application. the layout should be the typical application-style :
a "west" panel containing a static tree menu, a "north" panel for banner,title
and toolbars (variable), and a "center" panel which hosts the actual content.
within the center panel I do not need (nor wish to) have multiple "pages" active
at any one time. The idea is that the user clicks options on the left menu,and
the center panel changes to show the relevant sub-page. Think of an old-style
frameset, with the left-side <A>'s having the main frame as target, and you
have the exact navigation functionality I wish. back-and-forward actions are
handled by the application, not the browser buttons (for now).
Before discovering ExtJS a couple of days ago, I was planning to achieve this
using either good-ole framesets, or a single page with a single IFRAME for the
"center" region. I was also using jQuery for DOM manipulation and AJAX calls,
and a pure JSON data layer, served by PHP. I run into various issues with jQuery
visual components (the core is ok, but the components suck IMHO),and started looking
around. I found extJS and it was love at first sight. Ok, it is quite diffcult to
"get", the learning curve is huge, and the lack of a proper Programming Guide
(as opposed to the excellent Reference Guide) is a serious issue. Still, the
power of it is significant motivation for me to spend a lot of time on it!
(btw, is there any material anywhere, free or otherwise, that describes the
architectural concepts of ExtJS in some depth, like object/component model, layouts,
inheritance, life-cycle management, instance/ownership/garbage collection for components,etc ?)
After playing some time with the basic examples, I tried to implement my initial
design pattern, using an IFRAME hosted in a PANEL, which was hosted in a TABPANEL
which was hosted in a BORDER layout viewport.
(I used tabpanel because I dont know any better yet. My design does not need a tabPanel
for center, just a simple panel, I guess). This worked as expected, after some fiddling,
and I was very happy to see that the BORDER layout manages the 100% width/height issues
perfectly, something which has been bugging me in html for years now.
However, while playing with the samples, I realized that there was a different approach
to using an IFRAME, which I feel has signigicant advantages:
use a simple container element (the inner child panel I am using is ok for this),
and, every time the user clicks on a selection, load HTML dynamically into the element,
usign the element.getUpdater().update() technique. I had never considered this technique before,
because I needed scripts to be local to the sub-pages (the ones dynamically loaded),
and I did not realize before that Ajax calls can evaluate embedded scripts...
What I see as a HUGE advantage in this approach, is that the HTML "fragments" loaded
into the (single) panel do not need and in fact should not be complete stand-alone
html pages. in particular, all the Extjs setup code (stylesheets, scripts, any other of
my libraries) does not need to be in probably should NOT be included in the "sub-page".
Why is this an advantage ? because it gives a huge performance boost, since the run-time
environment is in fact fetched and compiled only once. by the same token, I now have
a perfect location to manage application-wide, client-side state, since the container
page is loaded only once. (I was expecting to do this via cross-frame calls in my old
design, a practice best avoided if possible).
OK, now come the bad news. since each sub-page gets loaded and parsed in the same,
static environment, the issue of namespace conflicts and memory leaks arises, I believe.
spefifically, what happens if page 1 contains a DIV with id "div1", and page 2 also
contains the same id ? I suspect that if I dont do anything about it, I end up with a document
having duplicate id's and you know what that means... Also, any functions contained in
a SCRIPT tag on page 1, will probably (and do) persist when page 2 is loaded.
When using IFRAMES or FRAMES, this issue does not arise, as each page runs in its own
namespace and sandbox.
I tried to address this issue by having the container page manage creation/destruction
of components, using code such as this:
<container page> :
if (tab.items) tab.removeAll(true); <-- test needed, because ITEMS does not exist by default
where 'tab1' is a plain PANEL which is child to the center TABPANEL
... component creation code,
... important : no calls to Ext.OnReady(), since the event will not fire anyway...
...for each new top-level component do this:
tb1.add(newComponent); // add this to container collection
I figured that, if the component/object model is anything like what I am used
from other environments, the garbage collection/memory management will be taken
care of by the container component, (not automatically, it seems, thus the
call to component.removeAll() in the container code)
so, finally, my questions:
*. is this design pattern I am trying to use here a valid and even desirable one,
or should I use another approach, and if so, which one, given the specifications
I described initially (singleton center area)?
*. is the way I found to manage creation/destruction of components the "proper"
and recommended way, is there a better/easier way, am I violating any
design/impementation rules of ExtJS ? is there a way that avoids having to
manually add the sub-page components to the container, a practice best left to
a framework and not to each individual page ? (for this discussion, I consider the
singleton main page as part of the application "framework")
*. would "namespaces" and "scope" help in any way augment my implementation ?
*. any other comments you wish to make on my approach ?
ok, that's it folks! a rather long message, I am afraid. I hope I am not boring
the h* out of you...
Let's try to break it to pieces and take questions one by one:
1. iframe vs panel load - it depends what better suits you. You can even combine them. Some (simpler) subpages can be loaded, more complex ones or from other domain can be in iframe. Take a look at ManagedIframe user extension.
Have you seen my examples? They're tree on the left and ifram in the center.
Thanks for the pointer, I will look into managedIframe. otoh, I never doubted that the tree/iframe combination would work just fine, I have been using it fir years. it is the OTHER one I am worried about.