Conversion of Script -> Component

Results 1 to 3 of 3

Thread: Conversion of Script -> Component

  1. #1
    Jason Miller Guest

    Default Conversion of Script -> Component

    Question Time: Given that I&#039ve got a lovely structure for included scripts so that I can rely on handy functions such as "isBlank" anywhere in any of my pages (both the "needs-to-be-script" and "should-be-component" bits), how can I optimize the availiablity of such tool functions when I convert them to components?<BR><BR>Option: Should I have multiple components calling each other? (Sounds messy; gets into dependencies I&#039m not sure I like at all... And where would the scripting context get determined?)<BR><BR>Option: Have the components include each other? (Doesn&#039t sound at all efficient, assuming I can make it work.)<BR><BR>Option: Use different classes in one big component? (Is it memory efficient? How do I call a function in another class? I&#039ve no experience here...)<BR><BR>Option: Something completely different. (This quandry is causing brain knottage.)<BR><BR>Thanks for any assists; feel free to correct any misconceptions you see above.<BR><BR>--Jason

  2. #2
    Matt Jacyno Guest

    Default RE: Conversion of Script -> Component

    I for one am glad this is being brought up. Refactoring your code (especially after the fact) is always painful, and as such, often ignored. But the fact that compiled code is faster doesn&#039t necessarily mean that it shouldn&#039t be scripted. Some might disagree and say that you should conserve every CPU cycle you can - but I, as a rule, do what makes the most sense to me.<BR><BR>But that could mean almost anything. It&#039s reasonable that objects that are obviously objects should be component-ized. But for my part, small utility functions that are pretty much independent of each other are ok remaining scripted.<BR><BR>In many applications, though, it doesn&#039t even apply, because ALL of your business logic is separated into compiled components. That&#039s where the real speed savings are, in my opinion. In that kind of architecture, your ASP is doing nothing more than working with the business objects so that it can send the UI to the client.<BR><BR>But before I get totally off-track. Here&#039s what I think of the various options you&#039ve presented:<BR>Multiple components calling each other: Yikes. I&#039d tend to agree with you; that gets messy in a hurry.<BR><BR>Components including each other: That&#039s basically the same as above, as far as I&#039m concerned. In fact, if you&#039re using Visual C++, it is the same, since it&#039s not as simple as just including something.<BR><BR>Different Classes, Same Component: This isn&#039t so bad, if you think about it (if I understand what you&#039re saying). Look at the ADO objects - they belong to the same "package". When you CreateObject, you&#039re passing in a string like "ADODB.Command" and "ADODB.Recordset". If you develop in Visual C++, you can add multiple ActiveX objects to the same project and it your ProgIDs should be grouped similarly.<BR><BR>But now this has become a big philosophical issue. In general:<BR>- Business logic should be compiled in the first place<BR>- It&#039s ok to leave things scripted if it makes sense<BR><BR>And it took me that long to get to the point... ;-)

  3. #3
    Jason Miller Guest

    Default Case in Point

    Of course, the other nice thing about scripting is that when your fickle clientele change their specifications (daily), not having to rebuild/reinstall is quite nice.<BR><BR>So very reminded of that when a file security level had to be downgraded today -- no stated reason, just a paradigm shift.<BR><BR>Jason &#060;sing: Oh, he&#039s a script kiddie and he&#039s okay!&#062; Miller

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts